Hi, On Fri, 14 Nov 2008, Chris Frey wrote: > 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 -- To unsubscribe from this list: 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
