From: Peter Valdemar Mørch (Lists) <4ux6as402@sneakemail.com>
Date: Thu, 08 Jan 2009 19:17:16 GMT
Subject: Re: Git (svn) merge - but ignore certain commits?
Message-ID: <4966513C.1010707@sneakemail.com>
In-Reply-To: <eaa105840901081029h220e06e4m1a1af693e908751e@mail.gmail.com>

Peter Harris git-at-peter.is-a-geek.org |Lists| wrote:
> Well, the real problem is that it *isn't* a repeated merge. Subversion
> rebased your trunk on you, so you...
> 
>> I ended up using git cherry-pick, and diff and patch / git diff and git
>> apply.
> 
> ...wind up needing to do this.
> 
> Don't rebase trunk (which implies ditching subversion,
> (un)fortunately), and repeated merges should Just Work. See, for
> example, the git repository itself, where the master branch is
> repeatedly merged into next.

Ah, yes. I understand. Thanks for making it more clear to me. There are 
two different problems at play here:

1) git svn doesn't help with the fact that svn can't handle the repeated 
merge problem (just noise here)

2) The git-only repeated-merge problem still exists, if I want a commit 
on the branch, but *do not* want it merged back to "master". This I 
still don't see a solution for. E.g.:

---A---B---C---D--+ "master"
     \--E---F---G-/  "branch"

Here I want F and G merged back to "master", but *not* E (which is a 
quick-and-dirty but safe version of B). That still seems not to be 
possible. What I did was:

---A---B---C---D--+- "master"
    |             /
    |\--F---G----+    "devbranch"
    |             \
     \--E----------+-   "branch"

(So F and G got merged from "devbranch" to both "master" and "branch", 
but E stayed on "branch" only)

I could do that because the system worked somewhat without E and I was 
able to develop/test F and G without E. But I'd still be out of luck if 
I needed to work on "branch". There seems to me to be no way in the 
first two-branch scenario to do repeated merges from "branch" to 
"master" if I need to avoid that E gets merged back to "master".

But thanks, Peter, for helping me understand. "git svn" and the fact 
that E happened to be a revert where just noise and had nothing to do 
with the core problem (2). That still has no solution, or am I missing 
something?

Peter
-- 
Peter Valdemar Mørch
http://www.morch.com