Cherry-picking with Dependencies
Dustin
I'm hoping to use a cherry-pick workflow both for maintaining a bit
of a linear view of history and to separate committer and author in
our changesets as we typically just have one author and one committer
(who presumably also reviewed the code).
It seems, however, that cherry-picking only performs one changeset
at a time and does not drag along dependencies (even when they're
verified).
Am I doing something incorrectly, or is this the state of things?
I'd like something along the behavior of a feature branch merge, but
applied as a series of cherry-picks. Is this possible?
Shawn Pearce
Or, if you were doing this with command line Git, you would do
something like:
git checkout feature-branch
git rebase master
git checkout master
git merge feature-branch
To linearize the feature-branch on top of master just before
it merges. But you might also have to force it to rewrite the
commits since you want the committer identity changed.
Currently Gerrit doesn't do this. In cherry-pick mode it ignores
dependencies and just does the pick of the one change you submitted.
In theory MergeOp could be taught this additional project mode,
but that code isn't pretty to go digging around in.
You can manually simulate it by submitting the changes in the proper
order, but that's easy to make a mistake on.
Alexander
> dependencies and just does the pick of the one change you submitted.
> In theory MergeOp could be taught this additional project mode,
> but that code isn't pretty to go digging around in.
Is there chance for this new MergeOp mode to be done ?
Luciano Carvalho
We use real cherrypick, and this kind of change would screw up with the way we are integrating code. (and other people too, I'm sure)
Only if another merge method was created for it, maybe...
Regards,
Luciano.
Connected by MOTOBLUR™ on T-Mobile
-----Original message-----
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
To unsubscribe from this group, send email to repo-discuss+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Alexander
It can be new merge strategy called 'Rebase strategy'.
Shawn Pearce
>> Please, don't do it... it wouldn't be cherry-picking anymore.
>
> It can be new merge strategy called 'Rebase strategy'.
Right. The correct way to implement this is to make a new strategy,
rather than modify the existing ones. It can be done, but I'm not
likely to code it myself. There are a lot of other things I want to
see get done first... so this will have to be a community
contribution. If someone sends a non-broken change for review
implementing this new strategy, I'll include it. :-)