Hi,
On Mon, 23 Apr 2007, Santi Béjar wrote:
> On 4/23/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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