search for: reflogs

...: $ mkdir foo $ cd foo $ git init Initialized empty Git repository in .git/ $ echo hi > blort $ git add . $ git commit -m create Created initial commit 4ae9415: create 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 blort and then attempt to expire the reflogs $ git-reflog --expire --all on ext3, git-reflog completes its work and exits immediately; and on btrfs, it gets stuck in some sort of loop that causes it to allocate more and more memory until I kill it or it pushes the machine into OOM. Kernel is 2.6.24 or so on x86-64. -- Paul Collins Wel...

dag at cray.com (David A. Greene) writes: > Jason Kim <jasonwkim at google.com> writes: > >> I believe git has a similar system for maintaining "branches of patches"  > > A pointer/tutorial on how to do this would be most welcome. It depends on the definition of "branches of patches" ;-). I manage my patches with "git rebase -i", which

Jason Kim <jasonwkim at google.com> writes: > I believe git has a similar system for maintaining "branches of patches"  A pointer/tutorial on how to do this would be most welcome. -Dave

On Wed, Feb 24, 2016 at 10:21 PM Pete Cooper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > Sent from my iPhone > > > On Feb 24, 2016, at 6:25 PM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I just want to clarify in case anyone is confused: I am in no way > suggesting that we would use pull requests,

I don't intend to weigh in on either side, but just give a perspective on a few questions asked. >From an outsiders perspective, that list isn't what I'd typically describe as the workflow, since it makes "fork" and "branch" sound like difficult operations. This sounds akin to thinking that someone would reclone the svn repo before working on a new

Sorry for the late reply to this ... On Tue, Apr 30, 2019 at 06:28:01PM +0200, Pino Toscano wrote: > On Friday, 9 February 2018 19:01:53 CEST Richard W.M. Jones wrote: > > My contention is that the libguestfs git repository is too large and > > unwieldy. There are too many separate, unrelated projects and as a > > result of that the source has too many dependencies and takes

On Thu, Nov 7, 2019 at 9:32 AM Finkel, Hal J. via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 11/7/19 10:13 AM, Jameson Nash wrote: > > I don't intend to weigh in on either side, but just give a perspective on > a few questions asked. > > From an outsiders perspective, that list isn't what I'd typically describe > as the workflow, since it makes

Hi Linus, This is a huge set of several partly interrelated (and concurrently developed) changes, which is why the branch history is messier than one would like. The *really* big items are two humonguous patchsets mostly developed by Yinghai Lu at my request, which completely revamps the way we create initial page tables. In particular, rather than estimating how much memory we will need for

Hi Linus, This is a huge set of several partly interrelated (and concurrently developed) changes, which is why the branch history is messier than one would like. The *really* big items are two humonguous patchsets mostly developed by Yinghai Lu at my request, which completely revamps the way we create initial page tables. In particular, rather than estimating how much memory we will need for

Hi Linus, This is a huge set of several partly interrelated (and concurrently developed) changes, which is why the branch history is messier than one would like. The *really* big items are two humonguous patchsets mostly developed by Yinghai Lu at my request, which completely revamps the way we create initial page tables. In particular, rather than estimating how much memory we will need for

I think that it's really important that we try to strike some balance here. Based on my experience, this thread, and offline conversations, two things seem clear to me: 1. Overall, Phabricator is a superior tool for managing code reviews and some related processes (although GitHub's tools certainly have some benefits, and both are getting better over time). 2. Not accepting GitHub PRs