{"thread":{"id":"51309","subject":"cherry-pick strangeness","startedAt":"2019-06-13T22:40:23Z","lastAt":"2019-06-15T00:24:17Z","messageCount":4,"participants":["Vincent Legoll","Elijah Newren","Phil Hord"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"377204","messageId":"CAEwRq=ohKw8o0R3mtcr5E0fAeEX_OMo5qCiVx3EWwp5B3BKU9Q@mail.gmail.com","threadId":"51309","inReplyTo":null,"subject":"cherry-pick strangeness","fromName":"Vincent Legoll","fromEmail":"vincent.legoll@gmail.com","sentAt":"2019-06-13T22:40:10Z","receivedAt":"2019-06-13T22:40:23Z","isPatch":false,"sender":{"key":"vincent.legoll@gmail.com","avatar":null},"body":"Hello,\n\nI stumbled upon a strange behavior of cherry-pick,\nrunning the attached script yields different results\nfrom running the same command lines manually in\nan interactive shell, one after the other.\n\nI searched the man page and found no indications\nthat that should act in this way. It looks like the CLI\nargs \"--ff\" & \"--no-ff\" or the absence of it are not\ndoing the same in a script as in an interactive shell.\n\nI  asked in the IRC channel, and was asked to report\nit here.\n\nI tried to reproduce it in various environments, I\nran it in Centos 7, debian 9, ubuntu bionic & cosmic,\nalpine & fedora, in docker containers, all giving the\nsame results. The git versions tested range from\n1.8.3.1 to 2.21.0.\n\nTrying to reproduce, I created the attached script,\nwhich reports 3 times \"SAME\", whereas the case\nusing \"--no-ff\" should print \"DIFF\", if I'm not wrong\nin reading its manpage description.\n\nWhat am I missing ?\n\n-- \nVincent Legoll\n"},{"id":"377206","messageId":"CABPp-BGQ0frtOk7ZF4vnLdfeYCXibUaC4zUV1coTz=AzOvy8Lw@mail.gmail.com","threadId":"51309","inReplyTo":"CAEwRq=ohKw8o0R3mtcr5E0fAeEX_OMo5qCiVx3EWwp5B3BKU9Q@mail.gmail.com","subject":"Re: cherry-pick strangeness","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-06-13T22:56:43Z","receivedAt":"2019-06-13T22:56:58Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, Jun 13, 2019 at 3:42 PM Vincent Legoll <vincent.legoll@gmail.com> wrote:\n>\n> Hello,\n>\n> I stumbled upon a strange behavior of cherry-pick,\n> running the attached script yields different results\n> from running the same command lines manually in\n> an interactive shell, one after the other.\n>\n> I searched the man page and found no indications\n> that that should act in this way. It looks like the CLI\n> args \"--ff\" & \"--no-ff\" or the absence of it are not\n> doing the same in a script as in an interactive shell.\n>\n> I  asked in the IRC channel, and was asked to report\n> it here.\n>\n> I tried to reproduce it in various environments, I\n> ran it in Centos 7, debian 9, ubuntu bionic & cosmic,\n> alpine & fedora, in docker containers, all giving the\n> same results. The git versions tested range from\n> 1.8.3.1 to 2.21.0.\n>\n> Trying to reproduce, I created the attached script,\n> which reports 3 times \"SAME\", whereas the case\n> using \"--no-ff\" should print \"DIFF\", if I'm not wrong\n> in reading its manpage description.\n>\n> What am I missing ?\n\nWhen you cherry-pick a commit, it reapplies its diff on top of a\n(usually different) commit, preserving the author name/email/date, but\nthrowing away the committer name/email/date -- instead using your\nname/email and the time of the cherry-pick for the committer.  Since\nyou are transplanting on the same commit, and you created both the\noriginal commit and the cherry-pick, the only thing that can be\ndifferent is the committer timestamp.  Git records timestamps down to\n1-second resolution.  If you run in a script, odds are that the\noriginal commit and the cherry-pick both run within the same second\n(though not always), and thus you end up with precisely the same\ncommit.  When you run interactively, you take longer than a second\nbetween commands, and thus have a different committer date which\nnaturally will have a different sha1sum.\n"},{"id":"377221","messageId":"CAEwRq=qufzNg_fBNPgSkV++VRHE2jE8q_iNBB1Fn=BQjTFRLEw@mail.gmail.com","threadId":"51309","inReplyTo":"CABPp-BGQ0frtOk7ZF4vnLdfeYCXibUaC4zUV1coTz=AzOvy8Lw@mail.gmail.com","subject":"Re: cherry-pick strangeness","fromName":"Vincent Legoll","fromEmail":"vincent.legoll@gmail.com","sentAt":"2019-06-14T07:26:30Z","receivedAt":"2019-06-14T07:26:43Z","isPatch":false,"sender":{"key":"vincent.legoll@gmail.com","avatar":null},"body":"Hello,\n\nOn Fri, Jun 14, 2019 at 12:56 AM Elijah Newren <newren@gmail.com> wrote:\n>\n> On Thu, Jun 13, 2019 at 3:42 PM Vincent Legoll <vincent.legoll@gmail.com> wrote:\n> >\n> > What am I missing ?\n>\n> When you cherry-pick a commit, it reapplies its diff on top of a\n> (usually different) commit, preserving the author name/email/date, but\n> throwing away the committer name/email/date -- instead using your\n> name/email and the time of the cherry-pick for the committer.  Since\n> you are transplanting on the same commit, and you created both the\n> original commit and the cherry-pick, the only thing that can be\n> different is the committer timestamp.  Git records timestamps down to\n> 1-second resolution.  If you run in a script, odds are that the\n> original commit and the cherry-pick both run within the same second\n> (though not always), and thus you end up with precisely the same\n> commit.  When you run interactively, you take longer than a second\n> between commands, and thus have a different committer date which\n> naturally will have a different sha1sum.\n\nThanks for the thorough explanation.\n\nLooks like this has nothing to do with \"--[no-]ff\" at all.\n\nSo if I put a \"sleep 2\" before each cherry-pick I won't get to see that\nbehavior, or if I had used something that changes the commit message\n(\"-x\", \"-s\" or maybe even \"-S\") ?\n\nShouldn't something about that be added to the man page to avoid\npeople scratch their heads ? (I can try to cook something if this is\ndeemed acceptable)\n\n-- \nVincent Legoll\n"},{"id":"377277","messageId":"CABURp0p3iwizpZNR+aeAK3_sj7v2mu487AD57PiZG4fgne+tww@mail.gmail.com","threadId":"51309","inReplyTo":"CAEwRq=qufzNg_fBNPgSkV++VRHE2jE8q_iNBB1Fn=BQjTFRLEw@mail.gmail.com","subject":"Re: cherry-pick strangeness","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2019-06-15T00:24:00Z","receivedAt":"2019-06-15T00:24:17Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Fri, Jun 14, 2019 at 12:29 AM Vincent Legoll\n<vincent.legoll@gmail.com> wrote:\n> On Fri, Jun 14, 2019 at 12:56 AM Elijah Newren <newren@gmail.com> wrote:\n> > When you cherry-pick a commit, it reapplies its diff on top of a\n> > (usually different) commit, preserving the author name/email/date, but\n> > throwing away the committer name/email/date -- instead using your\n> > name/email and the time of the cherry-pick for the committer.  Since\n> > you are transplanting on the same commit, and you created both the\n> > original commit and the cherry-pick, the only thing that can be\n> > different is the committer timestamp.  Git records timestamps down to\n> > 1-second resolution.  If you run in a script, odds are that the\n> > original commit and the cherry-pick both run within the same second\n> > (though not always), and thus you end up with precisely the same\n> > commit.  When you run interactively, you take longer than a second\n> > between commands, and thus have a different committer date which\n> > naturally will have a different sha1sum.\n>\n> Thanks for the thorough explanation.\n>\n> Looks like this has nothing to do with \"--[no-]ff\" at all.\n>\n> Shouldn't something about that be added to the man page to avoid\n> people scratch their heads ? (I can try to cook something if this is\n> deemed acceptable)\n\nPatches to documentation are welcome, but I'm not sure what you'd say.\nIs it just a note to point out that the HEAD resulting from\ncherry-pick is not guaranteed to be unique?  That seems too noisy for\nsomething which is inconsequential to most users, to me.  But others\nmay disagree.\n"}]}