Re: Joining cg-*-id

On Tue, 20 Sep 2005, Petr Baudis wrote:

quoted

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.

No, it's _not_ sensible or well-defined.

The order of the parents does not matter. It fundamentally _cannot_ 
matter. I realize that both git and cogito put the "primary parent" first, 
but that doesn't help one iota - because git is distributed, if the other 
side merged and we just did a fast-forward, the "primary parent" will be 
the _other_ side.

In other words, anybody who thinks that the order of parents is meaningful 
is in for some nasty shocks. It really _fundamentally_ isn't true. I 
realize that's hard to accept, but it's a truism in a distributed system. 
You really cannot have parent ordering and distribution at the same time.

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).

It's not sensible regardless of how you order things. There _is_ no 
ordering. 

So if you give a date, and there is a merge after that date, you will
always have at least two ways to reach the next older commit (now, if
you're lucky, it will be a common one and unambiguous, but more commonly
you'll simply have _two_ commits that are "most recent commit older than
the date".

And if you select one of them at random (or by deciding which parent is 
the "primary" one), then 

	git diff yesterday..

will show not the changes since yesterday, but _all_ the changes that came 
in through the merge.

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?

The only guarantees topo-ordering gives is that a parent will be shown 
before its children. So it may still mix up commits that happened 
between two parallell workflows, unlike merge-order that will always show 
one parallell chain of development as a contiguous set of commits.

Only merge-order gives any meaning to the order of the parents, but as 
mentioned, that is irrelevant - a merge on the other side will "flip" the 
whole world-view.

And they happen.

		Linus