git rev-list --boundary from..to

git rev-list --boundary from..to

[Santi Béjar]

Hi *,

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

  Thank you in advance

  Santi

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

[Johannes Schindelin]

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

Hi,

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. While I agree 
that it was nicer to scripts earlier, IMHO it was incorrect, too.

Hth,
Dscho

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

[Santi Béjar]

On 4/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> 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).


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

Santi

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

[Johannes Schindelin]

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