On 12/05/12 01:09, Konstantin Khomoutov wrote:
On Fri, May 11, 2012 at 09:50:18PM +0300, Nikos Chantziaras wrote:
The problem with rebasing and a public repo would only appear here if
you would have managed to push exp into that public repo after
committing X or Y. If the exp branch ends in C in the remote repo,
it's fine to rebase X->Y in your local version of exp.
exp contains pushed commits and has diverged from master. master
also contains commits made after exp was branched. Most of the new
commits in master need to also be applied to exp, but not all, since
some of them touch code that has been replaced with a different
implementation in exp. (So in this case, exp doesn't add new
features; it rewrites part of master using a better implementation.)
It seems I need to use cherry-pick (which looks like the equivalent
of hg export/import.)
Yes, to me it looks like a case for cherry-picking.
I suppose this won't break things for the future when exp will finally
be merged back into master?
It's hard to tell precisely.
Git is rather good at merging, but cherry-picked commits bear no meta
information about what they result from (contrary to merge commits) so
when merging "exp" back to "master", it will be up to textual merging
machinery to detect equivalent text changes in both lines of history.
Thanks for the helpful explanations, Konstantin. I think cherry-picking
is even better suited here than I originally thought. It seems that it
doesn't even make sense to merge exp into master. The nature of exp
pretty much suggests that master will be deleted and exp made the new
master. So merging is not even needed. (Not sure if you can delete a
branch in Git though, or if it's even advisable; will need to look this up.)
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at