emacs-devel
[Top][All Lists]
Advanced

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

Re: Freeze is almost here


From: David Engster
Subject: Re: Freeze is almost here
Date: Sat, 14 Nov 2015 15:37:51 +0100
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.5 (gnu/linux)

Eli Zaretskii writes:
>> From: David Engster <address@hidden>
>> Cc: address@hidden,  address@hidden,  address@hidden
>> Date: Sat, 14 Nov 2015 13:57:34 +0100
>
>> 
>> David Engster writes:
>> > I see now that master was merged into emacs-25. Is this now the new
>> > workflow? If so, there's not much point in keeping gitmerge.el anyway.
>> 
>> Sorry, forget what I said. I forgot the we don't freeze master anymore,
>> so I guess this was a one-time merge just to forward emacs-25. I was
>> just confused because git couldn't detect the cherry-picks, but this is
>> because of this merge from master.
>
> Could you describe the conditions necessary for gitmerge to detect
> cherry-picks?  I see that it uses --cherry-mark, but would that mark
> cherry-picks whose commit message was edited by "cherry-pick -e"?

Yes. Cherry-picks are detected through the "patch-id", which is not
affected by the commit message but only by the diff (see 'git help
patch-id'). This is why it's fine to change the commit message, but when
you resolve a conflict, the patch-id will usually change.

But when you later *merge* the branch from which you cherry-picked (like
we did with 'master'), git of course sees the cherry-picked commits as
merged, and hence does not check the patch-id later as well (most likely
because that would be slow). At least that's how I understand it.

> Also, what about the effect of the "cherry-pick -x" switch, does
> affect gitmerge in any way?

We could of course add "cherry picked" to the gitmerge-skip-regexp, but
otherwise, the '-x' has no affect on how git itself detects
cherry-picks.

-David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]