Re: merging emacs-24

["Stephen J. Turnbull" <stephen@xemacs.org>]

David Engster writes:

 > > You have to either cherry-pick the ones you want instead of merging,
 > 
 > Which defies the point of merging, of course.
 > 
 > > or revert the ones you don't want after merging.
 > 
 > That's cumbersome when those commits have conflicts, which is very
 > common since it is often the reason they should be skipped in the first
 > place.

Sure, but *that is the choice*.  If you look at merge implementations
that claim to be able to skip commits, you will find that they amount
to "git rebase --interactive": ie, a sequence of *new* commits made
from diffs of the commits chosen.  If they're diligent, they may
identify an initial prefix of commits that can be merged unchanged,
but if they do, the resulting DAG will have two merges, which is
rarely what the user expects.

 > I think the easiest way to avoid this is to merge the remote branch
 > instead of the local tracking one.

It is mathematically impossible to merge a remote branch, at least if
you want a record of the history of commits in the local repo.[1]  A
merge always takes place in the repo being operated on, and the
relevant commits must be present there.  The difference between git
and other VCSes is that git leaves the copy of the remote branch and a
ref to it in the current repo, which is necessary if you want to
compare the actual history to the history constructed by a "merge"
which skips commits.  (Of course in the case of a true merge, the
tracking branch is only a ref -- there are no commits other than those
needed to complete the local branch in it.  In this case all of git,
hg, and bzr contain the complete remote branch in the local repo.)

Footnotes: 
[1]  That is, technically you could replace an actual commit with a
URL to a repo containing the needed commit and all dependent data, and
destroy all the corresponding data needed to construct conflicts after
the merge.  This is more or less a "shallow" repo in git, and it's
impossible to do operations on "sufficiently old" commits with a
shallow repo in git, and AFAIK it's not possible to deepen the repo --
you have reclone and then merge or even cherrypick new commits.