From: "Mike Stump" <mikest...@comcast.net>
On Aug 1, 2014, at 9:27 AM, Jakub Narębski <jna...@gmail.com> wrote:
Note that you should try to avoid cherry-picking, as they do not
leave trace in the graph of revisions.
Fine, then I want a new command to merge in a change into my branch
from another branch and I want merge to account for the motion and not
duplicate it when I merge that branch back into master. Funny thing
is, cherry and merge seem to be documented mostly to do exactly what I
want.
For example if you are creating a bugfix, instead of putting it
directly on maint, and then cherry-picking to master, it is better
to create a separate feature branch for this fix
You’re assuming that I’m the author of master, I’m not, I’m merely a
contributor. This tail doesn’t wag that dog. What that means is that
I cannot change the world to work around a simple bug in git.
There is also git-imerge, third party tool that is intended to help
merging changes (and make it possible to do it in incremental way).
Then remove git merge and replace it with git-imerge. :-) Anyway, I
read that, and I can see some beauty of that that might be nice in
complex merges. The problem is, I want git merge to work.
I was curious if svn handles this better the same or worse, and it did
it just fine. I know that a while ago, svn could not handle this, it
would do what git does currently. Apparently they figured out it was
a bug and fixed it. Have you guys figured out it is a bug yet? The
first step in solving a problem, is admitting you have a problem.
--
But that goes both ways, and is a philosophical issue about what is to
be expected in various cases. For some central control use styles, the
ideas behind _distributed_ version control are anathema and (Git) just
grinds away at the policies that are expected.
That said, Git doesn't claim to be perfect (and can't because of the
'relativity' that comes with being distributed - truth has to give way
to a web of trust). Also the artefacts that Git validates are at a
different level of abstraction i.e. the whole project as a commit,
rather than just a few/one file at a time.
In your example (when generalised) the problem is deciding when, in the
change sequence, the cherry pick is to be backed out, especially if
there are conflicts in the change sequence that would need fixing
anyway, and in a long change sequence that would be a lot of conflict
fix-ups, hence the current choice of getting the merge conflicts all
resolved in the one go.
The alternate case, mentioned/implied by Brian, is to use a rebase
(probably after duplicating the branch so as to retain the original if
required) so as to see each patch/changeset being applied, and doing
any/many conflit resolutions as they appear, before finally doing any
merge of the new line of development back into the mainline (which again
presumes your earlier resolutions don't cause more conflicts on that
merge). But do note that I've hidden the problem of deciding where the
rebase start point should be, relative to the merge point, because
that's actually where the original problem is hidden (which bits merge
with what!)
git-imerge is a visual tool to show which bits merge cleanly with what
between two change sequences.
Selecting a compatible workflow is a problem of usage, rather than a
problem in Git. If Git has a problem, it's that it has too many ways of
doing things, leaving most of us with too much rope entangled round our
neck.
--
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
