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
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
On 4/23/07, Johannes Schindelin [off-list ref] wrote:
Hi,
On Mon, 23 Apr 2007, Santi Béjar wrote:
quoted
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
Hi,
On Mon, 23 Apr 2007, Santi Béjar wrote:
On 4/23/07, Johannes Schindelin [off-list ref] wrote:
quoted
On Mon, 23 Apr 2007, Santi Béjar wrote:
quoted
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.
quoted
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