Re: multiple-commit cherry-pick?

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 14 Nov 2008, Chris Frey wrote:
> 
> Would it be possible to add "range" support to a subset of commands by
> using a git-range wrapper?

It would be better to just extend the SHA-1 arithmetic. We could do it, no 
problem. It's just a SMOP.

For example, right now the arithmetic is entirely "flat", with no 
precedence, no nesting, nothing but a single level of set operations. We 
could extend it to be hierarchical.

So we _could_ do something like

	git log {a..b} {c..d ^e}

and just declare that { $args } is a self-contained "subset", and 
effectively becomes the same thing as "$(git rev-list $args)" but with 
magic no-walking semantics (ie all walking is done only _within_ the { }, 
not between different groups.

You literally _can_ do it right now that way:

	git log --no-walk $(git rev-list HEAD~5..HEAD~3) $(git rev-list HEAD~1..)

actually works, but that will hit argument size limits on many platforms 
really quickly.

So we could make a '{ }' in the argument space basically do a SHA1 
expansion of the range inside, and imply --no-walk. It's _not_ entirely 
trivial, because we'd need to handle the fact that object flags are 
sticky, and clear them in between invocations of multiple ranges, but it's 
not _fundmanetally_ difficult. It's just that somebody would need to do 
it.

		Linus