Re: git rev-list --boundary from..to

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 23, 2007, 14:53 UTC
Message-ID: <Pine.LNX.4.64.0704231650280.8822@racer.site>
In-Reply-To: <8aa486160704230738t75c90777k3787032fa4e348fb@mail.gmail.com>

Hi,

On Mon, 23 Apr 2007, Santi Béjar wrote:

Show 24 quoted lines

> On 4/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Mon, 23 Apr 2007, Santi Béjar wrote:
> >
> > >  git rev-list ${order} --boundary ${commitlimit}
> > >
> > >  is what is used in gitk. In v1.5.0.3:
> > >
> > >  $ gitk from..to
> > >
> > > shows the boundary commits next to the child, but it is no longer the
> > > case since v1.5.0.3-290-g86ab490.
> > >
> > >  Now all the boundary commits are at the bottom.
> > >
> > > While at it, when used with --max-count they are at the bottom too,
> > > and I understand why, but is there a way to tell "show me the boundary
> > > commits next to the child even if it means it takes more time"?
> >
> > I'd say "--parents", and infer the relevant information.
> 
> Sorry, I think I did not expressed it quite well. The "next to the 
> child" was about the order git-rev-list outputs the commits, not about 
> the parent information (moreover gitk uses --parents).

I meant that you can use "--parents" to reorder the revs, so that the boundary commits come directly after their children.

Show 5 quoted lines

> > While I agree that it was nicer to scripts earlier, IMHO it was 
> > incorrect, too.
> 
> Sorry but I do not understand what is incorrect. Are you talking about 
> the regression or about the --max-count question?

AFAICT the calculation of what makes a boundary commit was wrong before, and as a consequence of the fixed method, you see the boundary commits at the end.

To "fix" the order back to what you are used to, rev-list would have to do a specialized topological sort on top of what it does right now. Since not all users of rev-list--boundary need that, it should not be changed IMHO, at least by default.

Ciao, Dscho