Re: rev-list --cherry-pick and context lines

[lists@haller-berlin.de (Stefan Haller)]

Michael J Gruber <git@drmicha.warpmail.net> wrote:

> Stefan Haller venit, vidit, dixit 02.09.2011 12:35:
> > Consider two commits on different branches, one with this patch:
> > 
> >     diff --git a/file.txt b/file.txt
> >     index 704fa27..2f7e74c 100644
> >     --- a/file.txt
> >     +++ b/file.txt
> >     @@ -1,3 +1,3 @@
> >      old_context
> >      
> >     -foo
> >     +bar
> > 
> > and the other with this patch:
> > 
> >     diff --git a/file.txt b/file.txt
> >     index f35051b..8c7de32 100644
> >     --- a/file.txt
> >     +++ b/file.txt
> >     @@ -1,3 +1,3 @@
> >      new_context
> >      
> >     -foo
> >     +bar
> > 
> > If I run "git rev-list --cherry-pick --left-right branch1...branch2", it
> > reports both commits as being genuine commits on their respective
> > branch, even though I consider their patches to be the same.
> > 
> > I guess for my purpose I would like to have patch-ids that ignore
> > context (or that use only one line of context, I'm not sure which).
> > 
> > In fact, if I do "git show <commit> -U1 | git patch-id", both commits
> > show the same id.
> > 
> > So, would it make sense to have a parameter for git-rev-list (and
> > git-cherry) that lets you specify how much context to be used for the
> > patch ids?
> 
> It would be a bit like the patch below. "git log" accepts diff options already.
> But:
> [...]

Thanks a lot.  I can't contribute much to answering your "But:"
questions; I can only add more questions myself. :-)

Is there a reason why the hard-coded default is 3 in the current code?
It seems to me that 1 would be a better choice; it would mean "patches
are equal if their added/removed lines are the same, and they could be
cherry-picked without conflicts."

Now, I'm in a situation where I'll be stuck with git 1.7.1 for quite a
while, so no patch is going to help me.  It looks like the only way to
get the behaviour I want is to reimplement git-rev-list --cherry-pick
myself, feeding each patch to git-patch-id, right? (Horribly
inefficient, but might be good enough for my purpose. Just wondering if
I'm missing a smarter way to solve it.)

Thanks,
   Stefan


-- 
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/