Re: [PATCH] Stop git-rev-list at sha1 match
- From
- Thomas Gleixner <tglx@linutronix.de>
- Date
- May 11, 2005, 23:08 UTC
- 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:
Show 15 quoted lines
> > 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