From: Jeff King <peff@peff.net>
To: Casey Dahlin <cdahlin@redhat.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: [PATCH] logging branch deletion to help recovering from mistakes
Date: Tue, 7 Dec 2010 13:12:01 -0500 [thread overview]
Message-ID: <20101207181201.GB26137@sigill.intra.peff.net> (raw)
In-Reply-To: <20101207175418.GU355@fearengine.rdu.redhat.com>
On Tue, Dec 07, 2010 at 12:54:18PM -0500, Casey Dahlin wrote:
> On Tue, Dec 07, 2010 at 11:45:20AM -0600, Jonathan Nieder wrote:
> > Casey Dahlin wrote:
> >
> > > Could commits made onto a detached head also show up here? Or is that
> > > better thwarted with another mechanism?
> >
> > I think that's better thwarted with the HEAD reflog:
> >
> > $ git log -g HEAD
>
> I was more worried about changes that were made onto a detached head,
> and then the head was reattached, leaving the new commits dangling.
>
> The end result is identical to a deleted branch, just wondering if we
> should note it in the same place.
We have enough information in the HEAD reflog already to reconstruct
those sorts of things.
You can detect entering and leaving the detached HEAD in the reflog. The
reflog comments look something like this:
checkout: moving from $SOME_BRANCH to $SOME_SHA1
commit: $SOME_COMMIT_MESSAGE
checkout: moving from $SOME_OTHER_SHA1 to $BRANCH|$SHA1
So from that you can see that we entered a detached HEAD state, made a
commit, and that commit became dangling when we moved. One could write a
script to search for these cases (but note that most detached instances
just involve rebasing, which is probably not interesting, as we install
the result into the branch tip at the end).
I don't think this belongs in the same realm as "deleted branches", but
I do think we could have a special option to "git fsck" to stick these
into lost-found.
-Peff
prev parent reply other threads:[~2010-12-07 18:12 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-06 21:16 [PATCH] logging branch deletion to help recovering from mistakes Junio C Hamano
2010-12-06 21:55 ` Štěpán Němec
2010-12-06 23:14 ` Andreas Schwab
2010-12-07 1:18 ` Nguyen Thai Ngoc Duy
2010-12-07 6:28 ` Junio C Hamano
2010-12-07 11:37 ` Nguyen Thai Ngoc Duy
2010-12-07 15:25 ` Michael J Gruber
2010-12-07 16:25 ` Nguyen Thai Ngoc Duy
2010-12-07 16:22 ` Jakub Narebski
2010-12-07 16:26 ` Nguyen Thai Ngoc Duy
2010-12-07 17:06 ` Jeff King
2010-12-07 18:14 ` Shawn Pearce
2010-12-07 18:20 ` Jeff King
2010-12-07 18:23 ` Shawn O. Pearce
2010-12-07 18:35 ` Jeff King
2010-12-07 18:37 ` Shawn O. Pearce
2010-12-07 18:39 ` Jeff King
2010-12-07 18:41 ` Shawn O. Pearce
2010-12-07 19:21 ` Junio C Hamano
2010-12-07 19:38 ` Jeff King
2010-12-07 16:23 ` Casey Dahlin
2010-12-07 17:45 ` Jonathan Nieder
2010-12-07 17:54 ` Casey Dahlin
2010-12-07 18:02 ` Jonathan Nieder
2010-12-07 18:26 ` Casey Dahlin
2010-12-07 20:25 ` Junio C Hamano
2010-12-07 20:55 ` Jonathan Nieder
2010-12-07 18:12 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101207181201.GB26137@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=cdahlin@redhat.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).