threads / discuss / 7795

git rev-list --boundary from..to

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

## tl;dr

4 messages between Apr 23, 2007 and Apr 23, 2007.

replies: 3people: 2as markdown or json

Santi Béjar· Apr 23, 2007, 13:34 UTC · lore
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
Johannes Schindelin· Apr 23, 2007, 14:25 UTC · re: Santi Béjar · lore

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

Hi,
On Mon, 23 Apr 2007, Santi Béjar wrote:
Show 14 quoted lines
>  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

Santi Béjar· Apr 23, 2007, 14:38 UTC · re: Johannes Schindelin · lore

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

On 4/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 20 quoted lines
> 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
Johannes Schindelin· Apr 23, 2007, 14:53 UTC · re: Santi Béjar · lore

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

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

← back to recent threads