Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] Cherry-pick & Gerrit Change-ID


On 12/21/2011 12:46 PM, Matthias Sohn wrote:
> 2011/12/21 Markus Duft <markus.duft@xxxxxxxxxx <mailto:markus.duft@xxxxxxxxxx>>
> 
> 
> 
>     On 12/21/2011 09:46 AM, Matthias Sohn wrote:
>     > 2011/12/21 Markus Duft <markus.duft@xxxxxxxxxx <mailto:markus.duft@xxxxxxxxxx> <mailto:markus.duft@xxxxxxxxxx <mailto:markus.duft@xxxxxxxxxx>>>
>     >
>     >     Hey!
>     >
>     >     How should the gerrit change-id generation in egit behave when cherry-picking a commit to another branch? I observed:
>     >
>     >      * when there is no conflict, the same id is used
>     >      * when there is a conflict and i have to use the commit dialog, a new id is generated
>     >
>     >     is this intention? or should i report a bug?
>     >
>     >
>     > this looks inconsistent and is probably caused by the fact that
>     > change-id generation is a feature of the commit dialog which isn't
>     > used when cherry-pick succeeds without conflicts.
> 
>     mhm, i thought so ...
> 
>     >
>     > Though I am not sure what's the correct behavior as AFAIK Gerrit behavior
>     > changed from 2.1.x to 2.2. I think Gerrit 2.1.x rejects pushing changes with
>     > the same change-id to multiple branches whereas Gerrit 2.2 now
>     > can handle that.
> 
>     the problem also arises when the gerrit target branch stays all the same, but the change is cherry picked locally onto a different feature branch (for example to break the dependency on another commit, that i don't want to have in my branch)
> 
> 
> maybe we can associate a local branch with the branch on the Gerrit server it's aiming at
> extending the ideas discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=309578

maybe, but i don't have strong feeling in either direction here, as i don't see a direct relation. when the commit dialog is invoked after a merge or cherry-pick, it does get a message pre-filled. why not act like when amending, and keep the change id that was in the original commit anyway? i see no reason why it is thrown away and re-created.

Regards,
Markus

> 
> -- 
> Matthias


Back to the top