Hi,
I was thinking about a sort of symmetric to rebase, a kind of
"intelligent" mass cherry-pick. For the sake of example let's call it
"basere", although a better name would have to be found.
While
git rebase UPSTREAM
moves the *current* branch (and any commit in it, but not in UPSTREAM)
on top of UPSTREAM,
git basere UPSTREAM
would "cherry-pick" all commits in UPSTREAM that are not in HEAD to
the current branch.
git cherry-pick ..UPSTREAM
*nearly* does what I want, except that it lacks rebase's intelligence
of skipping commits that do the same textual changes as a commit
already in the current branch. So maybe it should be an option to
cherry-pick rather than a new command? E.g. --skip-same? What about
making it cherry-picks *default* behaviour?
Why do I think it is useful? Take the case of a developer following
two different origins A and B, and B uses rebase (not merge) to
integrate changes from A, but not as often as one would like. A could
for example be the "official" tree (e.g. linux Linus tree), and B a
feature branch of a developer that is meant to eventually go into A
"cleanly" at some future time and A's policy is that one has to rebase
before sending a merge request. Then another developer wants to keep
up with changes from *both* A and B. So, the situation could look
like:
A---A---A remotes/A/master
/
X---X---B0---B1---L master
\
B0---B1---B2--B3 remotes/B/master
So one does "git rebase remotes/A/master master" and one gets
A---A---A---B0---B1---L master
/
X---X
\
B0---B1---B2--B3 remotes/B/master
I'd like to go to the situation:
A---A---A---B0---B1---L---B2--B3 master
/
X---X
\
B0---B1---B2--B3 remotes/B/master
Without having to manually find the cutoff point "B2"
(or worse, if the history is more messy than that, as in:
A---A---A---B1---L master
/
X---X
\
B0---B1---B2--B3 remotes/B/master
)
The best way I have found to do that is:
git fetch B
git checkout --no-track -b TMP remotes/B/master
git rebase master
git checkout master
git merge --ff-only TMP
git branch -d TMP
or less commands but more messy/fragile (and more work for git):
git fetch B
git tag TMP
git rebase remotes/B/master
git rebase TMP
git tag -d TMP
but that is rather onerous for something that should be just one
command.
So what are your thoughts on that?
- Good idea? Would you take a patch that does something like that?
- Should it be cherry-picks's default behaviour?
- An option to cherry-pick?
- A new command? What name? Maybe "multi-cherry-pick"?
- An option to rebase, e.g. "--pull" or "--incoming" or "--here"?
("--pull" is probably too confusing wrt to "git pull"; people will
have trouble remembering which is which between "git pull
--rebase" and "git rebase --pull"...)
--
Lionel
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html