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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1749 bytes --]

Hi,

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

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

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