Re: git-format-patch possible regressions

On Thu, 25 May 2006, Marco Costalba wrote:

You _really_ shouldn't use this "mix two ranges" format.

It may have "worked" before, but it
 - worked differently from all other git ranges
 - it was really an implementation detail (handling each argument 
   separately)

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.

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).

			Linus