Re: [PATCH] Added guilt.reusebranch configuration option.

From: Junio C Hamano <gitster@pobox.com>
Date: May 23, 2013, 19:14 UTC
Message-ID: <7vobc1ecfg.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130523183759.GB1275@thunk.org>

Theodore Ts'o <tytso@mit.edu> writes:

Show 7 quoted lines

> Spekaing of which, what I'd really appreciate is timestamps associated
> with the reflog.  That's because the most common time when I've
> screwed something up is after doing a "git rebase -i" and so the
> reflog has a *huge* number of entries on it, and figuring out which
> entry in the reflog is the right one is painful.  If could tell at a
> glance when each entry of the reflog was created, it would make it a
> lot easier to untangle a tree mangled by git rebase -i.

Do you mean you want to go back to one specific step in "rebase -i", or you mean you want to go back to the state before "rebase -i"?

If the latter, one nice thing to know may be that "git log -g" is like "git log -g HEAD@{0}" and inspects the reflog associated with HEAD, and you can view individual steps of "rebase -i". On the other hand, "git log -g @{0}" (or "git log -g master@{0}" if you are on 'master' branch) will inspect the reflog associated with the current branch, and "rebase -i" appears as a single event (i.e. the tip before rewinding and replaying all the changes is replaced with the tip after that whole series of replaying). So the latter is what you want to use if you are interested in the state before the whole "rebase -i" operation.

Also you can ask "git log -g HEAD@{now}" and "git log -g @{now}". I agree with you that "git log --oneline -g @{now}" is very handy, and "git log --oneline --relative-date -g @{now}" is even better, as I can clearly see where the flurry of recent activities ends and which reflog entry is the one I was at 20 minutes ago before I started.

> This issue with reflogs not having timestamps isn't primarily about
> rewind safety,...

I think I may have answered this part with the above.

Show 5 quoted lines

> So what I've done in the past is to create a whole bunch of feature
> branches, and then merge them into the pu branch, and then only
> publish the pu branch.  And I try to get the feature branches cleaned
> up as quickly as I have time, so they can appear on the maint or
> master/next branches sooner rather than later.

Sounds very similar to somebody else is doing ;-)

Show 12 quoted lines

>> Just out of curiosity, do you ever have ref-renaming
>> requirements (like push = refs/heads/*:refs/heads/tt/*)?  We were
>> discussing that on another thread, but I haven't found an
>> implementation I'm happy with yet.
>
> In general, no, I don't do that, for the reasons stated above --- even
> publishing four branches gets to be confusing enough for people who
> are looking at my tree.
>
> I'm sure other people and other communities use git differently, so
> please insert the standard disclaimer that there's more than one way
> to skin a cat.

Agreed to both counts.  Thanks for comments.