On Mon, Aug 13, 2012 at 2:31 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> Makes sense. The shortlog example is a good example of sorting that
>> completely reorders the commit graph sometimes even making sense for
>> ranges. Thanks!
>
> By the way, does this topic relate to the
Martin von Zweigbergk writes:
> Makes sense. The shortlog example is a good example of sorting that
> completely reorders the commit graph sometimes even making sense for
> ranges. Thanks!
By the way, does this topic relate to the long stalled "rebase"
topic from you, and if so how?
--
To unsubs
On Mon, Aug 13, 2012 at 10:05 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>>
>> ... so is a migration desired? Or just
>> change the default for --no-walk from "sorted" to "unsorted" in git
>> 2.0?
>
> I think the proper support for Johannes's case should give users
> more control o
Martin von Zweigbergk writes:
> I also thought the sorting was just a bug. From what I understand by
> looking how the code has evolved, the sorting in the no-walk case was
> not intentional, but more of a consequence of the implementation. That
> patch you suggested was my first attempt and led
On Mon, Aug 13, 2012 at 12:17 AM, Junio C Hamano wrote:
> y...@google.com writes:
>
> [Administrivia: I somehow doubt y...@google.com would reach you, and
> futzed with the To: line above]
:-( Sorry, sendemail.from now set. (I apparently answered "y" instead
of just to accept the default.)
> I
Junio C Hamano writes:
> Would anything break if we take your patch, but without two
> possibilities to revs->no_walk option (i.e. we never sort under
> no_walk)?
By the way, by "would anything break", I do not just mean if our
existing tests trigger failures from "test_expect_success"; I
suspec
y...@google.com writes:
[Administrivia: I somehow doubt y...@google.com would reach you, and
futzed with the To: line above]
> From: Martin von Zweigbergk
>
> This series adds supports for 'git log --no-walk=unsorted', which
> should be useful for the re-roll of my mz/rebase-range series. It als
From: Martin von Zweigbergk
This series adds supports for 'git log --no-walk=unsorted', which
should be useful for the re-roll of my mz/rebase-range series. It also
addresses the bug in cherry-pick/revert, which makes it sort revisions
by date.
On Fri, Aug 10, 2012 at 11:28 PM, Junio C Hamano w
Martin von Zweigbergk writes:
> On Fri, Aug 10, 2012 at 2:38 PM, Junio C Hamano wrote:
>> Martin von Zweigbergk writes:
>>
>>> There is also cherry-pick/revert, which I _think_ does not really want
>>> the revisions sorted.
>>
>> Yes, I think sequencer.c::prepare_revs() is wrong to unconditoina
On Fri, Aug 10, 2012 at 2:38 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> There is also cherry-pick/revert, which I _think_ does not really want
>> the revisions sorted.
>
> Yes, I think sequencer.c::prepare_revs() is wrong to unconditoinally
> call prepare_revision_walk().
>
>
Martin von Zweigbergk writes:
> There is also cherry-pick/revert, which I _think_ does not really want
> the revisions sorted.
Yes, I think sequencer.c::prepare_revs() is wrong to unconditoinally
call prepare_revision_walk().
It instead should first check the revs->pending.objects list to see
i
A while ago when I was looking at revision.c, I was surprised to see
that commits are sorted even when --no-walk is passed, but as 8e64006
(Teach revision machinery about --no-walk, 2007-07-24) points out,
this can be useful for doing
$ git log --abbrev-commit --pretty=oneline --decorate --all --
12 matches
Mail list logo
