On Fri, 19 May 2006, Shawn Pearce wrote:

quoted text
> David K?gedal <davidk@lysator.liu.se> 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*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html