From: Marco Costalba <mcostalba@gmail.com>
Date: Thu, 25 May 2006 20:10:01 GMT
Subject: Re: git-format-patch possible regressions
Message-ID: <e5bfff550605251310n251df046r5124ec018688d321@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0605251233300.5623@g5.osdl.org>

On 5/25/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> The "x..y" format is defined to mean the same thing "y ^x", and that means
> that "HEAD^..HEAD HEAD^^..HEAD^" really does mean the same thing as
> "^HEAD^ ^HEAD^^ HEAD HEAD^", which in turn means the same thing as "^HEAD^
> HEAD" from a reachability standpoint (since HEAD^ is by definition
> reachable from HEAD, adding it won't change the revision list, and the
> same goes for ^HEAD^^ vs ^HEAD^).
>
> So thus "HEAD^..HEAD HEAD^^..HEAD^" really _is_ the same thing as
> "HEAD^..HEAD", and any tool that thought otherwise was just being
> very confused.
>

Perhaps I have chose the wrong example but it was  _only_
instrumental in better explaing the regression.

The general problem is how to format patches files named with
consecutive numbers starting from a set of possible unrelated
revisions.

> Now, we could choose to try to make "a..b" mean something else (ie make
> the "^a" part only meaningful for that particular "sub-query"), and yes,
> in many ways that would be a more intuitive thing, but it's not how git
> revision descriptions work currently, and if we make that change we should
> do it across the board.
>
> (It's not an easy change to make, but it should be possible by having
> multiple separate NECESSARY/UNNECESSARY bits, and make the revision
> walking logic a whole lot more complicated than it already is).
>
> So I'd argue that you should really do something like
>
>         ( git-rev-list a..b ; git-rev-list c..d ) |
>                 git-format-patch --stdin
>
> in qgit if you want the ranges to be truly independent.
>
> (And no, I don't think git-format-patch takes a "--stdin" argument, but it
> might not be unreasonable to add it as a generic revision walking
> argument for scripting like this).
>

To fix qgit problem could be enough to add/modify the option -nx to
make git-format-patch do not default with 0001 number but with x and
then simply call git-format-patch in a loop:

    for(int i = 0;  i  <selectedRevisions.count(); i++)
         git-format patch -n<i+1> selectedRevisions[i]  ^selectedRevisions[i];


But of course it is clear your suggestion could be a solution for
much broader cases.

    Marco