Re: Joining cg-*-id

From: Linus Torvalds <torvalds@osdl.org>
Date: Sep 20, 2005, 14:53 UTC
Message-ID: <Pine.LNX.4.58.0509200734440.2553@g5.osdl.org>
In-Reply-To: <20050920135735.GC1884@pasky.or.cz>

On Tue, 20 Sep 2005, Petr Baudis wrote:

Show 14 quoted lines

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