On 5/25/06, Linus Torvalds <torvalds@xxxxxxxx> 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
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html