Re: [BUG] multi-commit cherry-pick messes up the order of commits

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Jan 12, 2012, 17:26 UTC
Message-ID: <CALkWK0nJM2wUE9qzp38qjFFqCdwX9w0Jckxi1G=1=7adMxg2rw@mail.gmail.com>
In-Reply-To: <20120112171536.GA18102@sigill.intra.peff.net>

Hi Peff,

Jeff King wrote:

> It may even be possible to use
> heuristics to identify when --literal-order is needed, and eventually it
> could go away.

Yeah, that would be really nice.

> My only concern is that there are other parts of the revision machinery
> that depend on the date-ordering of the commit list.

Agreed. Looking at it another way, it's an opportunity to read revision.c, learn, and modernize some older parts :)

Show 8 quoted lines

> What would happen,
> for example, with:
>
>  git rev-list --literal-order --do-walk foo
>
> It probably doesn't make sense to allow literal-order without no-walk,
> anyway (which of course is the default in cherry-pick anyway, so it's
> not a big deal here).

I don't know if that particular case is a problem: there are some mutually exclusive options in revision.c already like:

  cannot combine --reverse with --graph

This'll just be another one of them.

Show 5 quoted lines

> I'm also not sure what:
>
>  git rev-list --literal-order foo..bar
>
> would or should do.

Instead of classifying it as an "ordering" option (as defined in Documentation/rev-list-options.txt), I think we should give it some sort of special status for now -- it can be combined with ordering options (of which date ordering is default anyway). For this specific question, I suspect that revision.c does a topo-ordering for commit ranges (I haven't read the code), so we have to make sure that whatever extra logic we add doesn't disrupt the existing logic in revision.c.

-- Ram