Theodore Ts'o <ty...@mit.edu> writes:
> 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.
> 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 ;-)
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
