Re: Joining cg-*-id

[Petr Baudis <pasky@suse.cz>]

Dear diary, on Tue, Sep 20, 2005 at 02:50:21AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Tue, 20 Sep 2005, Petr Baudis wrote:
> > But that semantics sucks, and I wouldn't mind changing it at all. I
> > think taking the previous commit works for everything but the start of
> > cg-log range, and it is how CVS behaves.
> 
> The thing is, it may have sensible behaviour for CVS, but only because CVS 
> doesn't have any notion of concurrent development (even a branch isn't 
> concurrent - it's totally separate, and when you merge it, it becomes just 
> one big diff at the time of the merge).
> 
> So I'd love to have
> 
> 	git diff yesterday..
> 
> but the fact is, there's no sensible semantics for it. _which_ yesterday? 
> There might be five different points that are "close to 24 hours ago", 
> along five different paths backwards in the history.

A well-defined meaning for this from Cogito standpoint would be "the
last commit on our HEAD before the date and all commits committed and
merged to the HEAD". In Cogito, you don't merge two branches _together_,
you merge one branch _into_ another (represented by the parents order),
so this would be sensible.

But we would have to sort the log in merge order for this to be possible
(and probably teach git-rev-list about it anyway).  I would absolutely
*love* to have cg-log in merge order instead of date order - longer I
see it the more I believe that it's evil and you should really want
merge order instead. The trouble is that cg-log would be no longer
incremental and would have to load the whole history first, a no-go for
any measurably long history.

By the way, did I understand it right that the only difference between
the results of merge ordering and topo ordering is the order commits
with regard to the order of parents?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.