Re: Tracking branch history

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 12 May 2006, Linus Torvalds wrote:

> Btw, the real problem with this is how to use it.
> 
> The only really valid use I see is to use it for date-based things, ie if 
> given a date, look up the most recent commit ID that is older than the 
> date in question. No other op seems to really make sense, but that one 
> does.
> 
> Now, the one other operation that is semantically sensible is to use the 
> list of commits to figure out a "path" through the commit space. However, 
> that path won't actually even be well-defined (a fast-forward pull/merge 
> can and often /will/ update the history in a way where it's impossible to 
> select one particular path to the previous commit listed in the commit 
> log).

I think that jumping around with reset is necessary to make this actually 
complicated; a fast-forward only happens if the new value descends from 
the old value, and a merge obviously descends from the old value. Sure, 
the non-linear history added by a merge will still be non-linear, but 
from the local user's point of view, it was all added in bulk by the 
merge.

I think the program creating the history should note the tricky cases, 
where the new value doesn't descend from the old value, which should be 
easy to identify. I'm not sure what should actually be done to report a 
reset in a changelog, either. The section of the log just before the reset 
is clearly a false start of some sort, and you probably want to do 
something special to list the commits which don't actually lead to the 
current state, but you probably want to report them, in case the reason 
you'd looking through this is that there was some benefit to a version 
that you ended up discarding, and you want to revisit that attempt.

I think in the always-forward case, there's a useful optimization to be 
had by having the rev-list-equivalent actually binning commits by the 
earliest points that descend from them, so you don't trace the local 
branch back to where other branches forked off over and over. But it seems 
to me otherwise pretty simple.

	-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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]