On Fri, 19 May 2006, Shawn Pearce wrote:
> David K?gedal <davidk@xxxxxxxxxxxxxx> wrote:
> > I noticed that some of this seems to be changing slightly with the
> > introduction of branch logs, but I don't know how those are supposed
> > to be used yet.
>
> $ git commit -a
> $ git pull . some/other-tag
> # go to lunch
> $ git pull . some/bad-stuff
> $ git commit -a
> # go home
> $ test...
> # realize this is all bad
> $ git reset --hard "master@{yesterday}"
>
> :-)
>
> Its really only useful for recording the history of your ref's state,
> so you can 'undo' a bad merge that you might have done a few days
> ago but not realized was bad until now.
I still think it's useful for presenting a local view of how things have
changed. I.e.:
$ git pull . stuff
# Notice that the diffstat is exciting
# What did I just get?
$ git log master@{5 minutes ago}..master
This is about the only easy way to find out that the fast-forward you just
did included merging a line which contains a commit from several weeks
ago. (Because the "before" state isn't easily accessible for a
fast-forward, and the date of the old commit puts it way back in a
date-ordered log.)
I still think that a local changelog, which groups the additions due to
each logged value, would be a useful way of viewing the history in a way
that's meaningful to the particular user, and I think it would fit user
expectations of gitweb (i.e., when looking at Linus's tree's summary,
things would be ordered by when they hit Linus's tree, not when they were
originally committed, so between the listing of the merge at 23:48:54
today and the one 7 minutes before would be those things which weren't in
Linus's tree during those 7 minutes).
-Daniel
*This .sig left intentionally blank*
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html