Re: patch vs. overwrite in bzr

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Wed, 04 Apr 2012 14:07:25 -0400
> 
> IIUC it's just difficult to do it "right" because it's largely
> incompatible with the way metadata/history is kept.  The best you can
> get is good support for two-way sync between identical branches (which is
> what we all use, where one of the branch is local to our machine and
> the other is on bzr.sv.gnu.org), but as soon as the two branches are
> supposed to be different the model breaks down.
> 
> The problem is similar to cherry-picking, but reversed: you want to be
> able to get all changes except for a few negative-cherrypicks.  E.g,
> "pull/merge from the Org branch all changes except for those few ones we
> don't want" (and inversely, they want to "pull from the Emacs branch,
> except for the file-renamings they did to adapt to their directory
> layout").

Would the problem be solved if such cherry-picking weren't needed?
That is, if the branches were exactly identical, but kept in two
different VCSes?  If this would solve the problem, then that's what
I'd suggest doing.  After all, all those differences sound very minor;
e.g., why not rename the files as the other guy does?

> Since the currently supported metadata can't be used, the solution ends
> up having to be "manual" and can probably work equally well for most
> VCS.  E.g. keep "tags" on both branches that record the last sync, and
> when a new sync is attempted, get the diff since last sync on each
> branch (using the tags), apply the patch to the other branch, commit and
> update the tags.

Did anyone consider using bzr-git as part of this?  It doesn't yet
support pushing to a git repo, but it does support "dpush", which
could be good enough.  And, of course, pulling from a git repository
is fully supported.