git-cherry-pick and author field in version 1.7.6.4

> in the last stable version (1.7.6.4), when I perform a
> git-cherry-pick, the initial author of the patch is erased whith my
> name (it was not the case in version 1.7.3.4 and prior). Is this
> behavior intended ? Is there an option to keep the initial author of
> the patch?

> On Wed, Oct 05, 2011 at 04:51:58PM +0200, Nicolas Dichtel wrote:
>
>> in the last stable version (1.7.6.4), when I perform a
>> git-cherry-pick, the initial author of the patch is erased whith my
>> name (it was not the case in version 1.7.3.4 and prior). Is this
>> behavior intended ? Is there an option to keep the initial author of
>> the patch?
>
> I can't reproduce your problem:
>
>    git init repo&&
>    cd repo&&
>    echo content>file&&  git add file&&  git commit -m base&&
>    echo changes>>file&&
>    git commit --author='Other Person<other@example.com>' -a -m other&&
>    git tag other&&
>    git reset --hard HEAD^&&
>    git cherry-pick other
>
> gives this output for the cherry-pick:
>
>    [master 6eb207f] other
>     Author: Other Person<other@example.com>
>     1 files changed, 1 insertions(+), 0 deletions(-)
>
> and the resulting commit looks good:
>
>    $ git log -1 --format='%an<%ae>'
>    Other Person<other@example.com>
>
> Does the script above work for you? If so, then what is different about
> your problematic case?

> Here is my sequence. I'm in a linux tree with a remote that point to
> linus tree and I want to cherry-pick a patch from this remote:
> 
> # git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
> [dev 87ce387] drivers/net/usb/asix.c: Fix unaligned accesses
>  1 files changed, 33 insertions(+), 1 deletions(-)
> # git log -1 --format='%an<%ae>'
> Nicolas Dichtel<nicolas.dichtel@6wind.com>
> # git log -1 --format='%an<%ae>' 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
> Neil Jones<NeilJay@gmail.com>
> #

> On Thu, Oct 06, 2011 at 09:51:06AM +0200, Nicolas Dichtel wrote:
>
>> Here is my sequence. I'm in a linux tree with a remote that point to
>> linus tree and I want to cherry-pick a patch from this remote:
>>
>> # git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
>> [dev 87ce387] drivers/net/usb/asix.c: Fix unaligned accesses
>>   1 files changed, 33 insertions(+), 1 deletions(-)
>> # git log -1 --format='%an<%ae>'
>> Nicolas Dichtel<nicolas.dichtel@6wind.com>
>> # git log -1 --format='%an<%ae>' 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
>> Neil Jones<NeilJay@gmail.com>
>> #
>
> Hmph. Odd:
>
>    $ cd linux-2.6
>    $ git checkout -b dev 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9^
>    Switched to a new branch 'dev'
>    $ git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
>    [dev 78929c2] drivers/net/usb/asix.c: Fix unaligned accesses
>     Author: Neil Jones<NeilJay@gmail.com>
>     1 files changed, 33 insertions(+), 1 deletions(-)
>    $ git log -1 --format='%an<%ae>'
>    Neil Jones<NeilJay@gmail.com>

>
>> Maybe it is related to the problem I've reported in another thread:
>> http://comments.gmane.org/gmane.comp.version-control.git/182853
>
> Possibly. That issue is about the commit that comes _after_ the
> cherry-pick, and in this instance, things are already wrong for you by
> the time the cherry-pick has completed.
>
> However, the problem has to do with leaving a stale state file in .git,
> so perhaps a previous partially-completed cherry-pick has left cruft in
> .git that is confusing this cherry-pick (i.e., I can't reproduce because
> it is being affected by something that happened before the commands
> above). So let's see what Jay comes up with for solving the other
> problem, and I suspect it may just fix this issue, too.

> >>Maybe it is related to the problem I've reported in another thread:
> >>http://comments.gmane.org/gmane.comp.version-control.git/182853
> >
> >Possibly. That issue is about the commit that comes _after_ the
> >cherry-pick, and in this instance, things are already wrong for you by
> >the time the cherry-pick has completed.
> >
> >However, the problem has to do with leaving a stale state file in .git,
> >so perhaps a previous partially-completed cherry-pick has left cruft in
> >.git that is confusing this cherry-pick (i.e., I can't reproduce because
> >it is being affected by something that happened before the commands
> >above). So let's see what Jay comes up with for solving the other
> >problem, and I suspect it may just fix this issue, too.
> I think so too. Will wait.

> On Thu, Oct 06, 2011 at 02:37:02PM +0200, Nicolas Dichtel wrote:
>
>>>> Maybe it is related to the problem I've reported in another thread:
>>>> http://comments.gmane.org/gmane.comp.version-control.git/182853
>>>
>>> Possibly. That issue is about the commit that comes _after_ the
>>> cherry-pick, and in this instance, things are already wrong for you by
>>> the time the cherry-pick has completed.
>>>
>>> However, the problem has to do with leaving a stale state file in .git,
>>> so perhaps a previous partially-completed cherry-pick has left cruft in
>>> .git that is confusing this cherry-pick (i.e., I can't reproduce because
>>> it is being affected by something that happened before the commands
>>> above). So let's see what Jay comes up with for solving the other
>>> problem, and I suspect it may just fix this issue, too.
>> I think so too. Will wait.
>
> Since you can reproduce this so readily, and since you said it seems to
> work with older versions of git, you might try bisecting. There's a
> reasonable chance it will just end up at Jay's CHERRY_PICK_HEAD commit,
> but it might be worth doing.