Re: multiple-commit cherry-pick?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 14, 2008, 14:00 UTC
Message-ID: <alpine.DEB.1.00.0811141452550.30769@pacific.mpi-cbg.de>
In-Reply-To: <20081114050822.GA23963@foursquare.net>

Hi,

On Fri, 14 Nov 2008, Chris Frey wrote:

Show 27 quoted lines

> On Mon, Nov 10, 2008 at 10:31:32PM +0100, Johannes Schindelin wrote:
> > On Mon, 10 Nov 2008, Alex Riesen wrote:
> > > for cs in HEAD^..HEAD HEAD~10; do
> > >   case "$cs"; in
> > >   *..*)
> > >      git format-patch --stdout "$cs"
> > >      ;;
> > >   *)
> > >      git show --pretty=email "$cs"
> > >      ;;
> > >   esac
> > > done
> > > 
> > > At least, this is what I have in mind and how I expect it to work.
> > 
> > That is not the way git-show is implemented (it uses setup_revisions() to 
> > check for validity and to parse the arguments), and I cannot think of any 
> > way to make this work without ugly workarounds.
> 
> Would it be possible to add "range" support to a subset of commands by
> using a git-range wrapper?
> 
> Hypothetical, pie-in-the-sky idea:
> 
> 	git range HEAD^..HEAD HEAD~10 -- show --pretty=email
> 	git range HEAD^..HEAD HEAD~10 -- log
> 	git range HEAD^..HEAD HEAD~10 -- cherry-pick

This is not really well defined is it?  What about

	git range HEAD -- log makefile

Where should it insert the "HEAD" argument?

Besides, I do not like how this muddies the semantics: if git range as you proposed it became part of Git, people _would_ get confused why "git range HEAD^..HEAD HEAD~10" interprets the range _differently_ from "git log HEAD^..HEAD HEAD~10".

Ciao, Dscho