search for: reflog

...: $ 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 We...

...y patches with "git rebase -i", which allows me to edit, combine, reorder, discard my local commits relatively easily. See for example: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html Git keeps tracks of what you do locally in a kind of meta-history called the reflog (i.e. when you rewrite history, the resulting history is the clean sequence of commits you want to show to the rest of the world, and the reflog keeps tracks of you mistakes and how you fixed them). See for example: http://gitready.com/intermediate/2009/02/09/reflog-your-safety-net.html The reflo...

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,

...lists these as events (e.g. "user force-pushed from abcdefg to gfedcba", where each of those are hyperlinks) in the comment feed. > how do i go back to previous revision Answering a slightly different question in the hopes someone finds this information useful: locally you can do `git reflog <branchname>` to get a history of the state of the HEAD of any tag on that particular machine for the last 90 days. On Thu, Nov 7, 2019 at 8:10 AM Nemanja Ivanovic via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I find Hal's analysis of this subject to be the most pragmati...

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

....g. "user force-pushed from abcdefg to gfedcba", where each of those are > hyperlinks) in the comment feed. > > > how do i go back to previous revision > Answering a slightly different question in the hopes someone finds this > information useful: locally you can do `git reflog <branchname>` to get a > history of the state of the HEAD of any tag on that particular machine for > the last 90 days. > > > On Thu, Nov 7, 2019 at 8:10 AM Nemanja Ivanovic via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I find Hal's analysis of...

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