Re: cherry-pick strangeness

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

On Fri, Jun 14, 2019 at 12:56 AM Elijah Newren <newren@xxxxxxxxx> wrote:
>
> On Thu, Jun 13, 2019 at 3:42 PM Vincent Legoll <vincent.legoll@xxxxxxxxx> wrote:
> >
> > 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.

Thanks for the thorough explanation.

Looks like this has nothing to do with "--[no-]ff" at all.

So if I put a "sleep 2" before each cherry-pick I won't get to see that
behavior, or if I had used something that changes the commit message
("-x", "-s" or maybe even "-S") ?

Shouldn't something about that be added to the man page to avoid
people scratch their heads ? (I can try to cook something if this is
deemed acceptable)

-- 
Vincent Legoll



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux