From: Thomas Gleixner <tglx@linutronix.de>
Date: Wed, 11 May 2005 23:08:34 GMT
Subject: Re: [PATCH] Stop git-rev-list at sha1 match
Message-ID: <1115852914.22180.170.camel@tglx>
In-Reply-To: <20050511225058.GK22686@pasky.ji.cz>

On Thu, 2005-05-12 at 00:50 +0200, Petr Baudis wrote:
> > Rn
> > ---- Stop = Rn-1
> > Rn-1
> > ---- Stop = Rn-2
> 
> Mn
> Mn-1
> 
> > Rn-2
> > ---- Stop = Rn-3
> > 
> > The diff between Rn and Rn-1 contains always the changes merged from M
> 
> Yes, but you get the merge commits again since rev-list follows all the
> parents.

That's plain wrong. The Mn(1) change hit repository r between revision
Rn and Rn-1 and nowhere else. 

Date is irrelevant. The only relevant thing is the parent child(s)
relationship.

What you get doing this is history cluttering. In the repository R it is
completely irrelevant when Mn resp. Mn-1 was created. The only relevant
point is when it was merged into repository R.

Bitkeeper does the same bogus thing to make changesets appear in a
linear order. Look at the changeset logs. If you diff the versions
exported by bitkeeper then you get complete nonsense. 

Please do not make the same mistake. 


tglx