Re: cherry-pick strangeness

From: Elijah Newren <newren@gmail.com>
Date: Jun 13, 2019, 22:56 UTC
Message-ID: <CABPp-BGQ0frtOk7ZF4vnLdfeYCXibUaC4zUV1coTz=AzOvy8Lw@mail.gmail.com>
In-Reply-To: <CAEwRq=ohKw8o0R3mtcr5E0fAeEX_OMo5qCiVx3EWwp5B3BKU9Q@mail.gmail.com>

On Thu, Jun 13, 2019 at 3:42 PM Vincent Legoll <vincent.legoll@gmail.com> wrote:

Show 28 quoted lines

>
> Hello,
>
> I stumbled upon a strange behavior of cherry-pick,
> running the attached script yields different results
> from running the same command lines manually in
> an interactive shell, one after the other.
>
> I searched the man page and found no indications
> that that should act in this way. It looks like the CLI
> args "--ff" & "--no-ff" or the absence of it are not
> doing the same in a script as in an interactive shell.
>
> I  asked in the IRC channel, and was asked to report
> it here.
>
> I tried to reproduce it in various environments, I
> ran it in Centos 7, debian 9, ubuntu bionic & cosmic,
> alpine & fedora, in docker containers, all giving the
> same results. The git versions tested range from
> 1.8.3.1 to 2.21.0.
>
> Trying to reproduce, I created the attached script,
> which reports 3 times "SAME", whereas the case
> using "--no-ff" should print "DIFF", if I'm not wrong
> in reading its manpage description.
>
> What am I missing ?

When you cherry-pick a commit, it reapplies its diff on top of a (usually different) commit, preserving the author name/email/date, but throwing away the committer name/email/date -- instead using your name/email and the time of the cherry-pick for the committer. Since you are transplanting on the same commit, and you created both the original commit and the cherry-pick, the only thing that can be different is the committer timestamp. Git records timestamps down to 1-second resolution. If you run in a script, odds are that the original commit and the cherry-pick both run within the same second (though not always), and thus you end up with precisely the same commit. When you run interactively, you take longer than a second between commands, and thus have a different committer date which naturally will have a different sha1sum.