Procedure for cherry-picking

[Jon Turney]

On 12/09/2024 00:08, Ken Brown wrote:
> I've been away from Cygwin development for a while, and I've forgotten 
> (or never knew) the conventional way of cherry-picking a commit from the 
> main branch to the cygwin-3_5 branch.  Here's the context:
> 
> Last February it was discovered that a build of Cygwin with -Og failed 
> because of some gcc warnings that were treated as errors.  Corinna fixed 
> this on the main branch in commit e99dbf6c25c3.  I just tried to build 
> the cygwin-3_5 branch without optimization and ran into the same 
> problem.  So Corinna's fix needs to be applied to that branch.  My 
> instinct is that I should checkout the branch and do
> 
>    git cherry-pick e99dbf6c25c3
> 
> and then amend the commit to add a note that it was cherry-picked.

If you use 'git cherry-pick -x' it automatically adds a note with the 
picked-from commit id.

Otherwise, the procedure you outline makes sense, and is what I do.

> The weird thing about this is that we would then have a commit dated Feb 
> 14 on top of a commit dated Sep 1.  Is that a problem?  If so, how 
> should I handle this?
  git separately tracks the commits "authored" and "committed" date, so 
I don't think this is even confusing. :)

(But even the committed date can be overridden with GIT_COMMITTER_DATE, 
so expecting these to be a linear series seems like a mistake...)