Re: multiple-commit cherry-pick?
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Nov 14, 2008, 16:59 UTC
- Message-ID
- <alpine.DEB.1.00.0811141758230.30769@pacific.mpi-cbg.de>
- In-Reply-To
- <alpine.LFD.2.00.0811140800540.3468@nehalem.linux-foundation.org>
Hi,
On Fri, 14 Nov 2008, Linus Torvalds wrote:
Show 23 quoted lines
> 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.Well, do not forget the case
git log ^HEAD^ {HEAD^..HEAD} $BLUBCiao, Dscho