Re: [PATCH] Stop git-rev-list at sha1 match

From: Petr Baudis <pasky@ucw.cz>
Date: May 11, 2005, 23:44 UTC
Message-ID: <20050511234455.GL22686@pasky.ji.cz>
In-Reply-To: <1115852914.22180.170.camel@tglx>

Dear diary, on Thu, May 12, 2005 at 01:08:34AM CEST, I got a letter where Thomas Gleixner <tglx@linutronix.de> told me that...

Show 22 quoted lines

> 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 I described is just how rev-list works (now), nothing more. This is what you get when you use rev-list.

Please see the thread of

5730     Apr 27 H. Peter Anvin  ( 0.2K) kernel.org now has gitweb installed

for extensive discussion on how (it is impossible or very hard) to do better.

So how would you order the list of commits?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor