Git (svn) merge - but ignore certain commits?

Git (svn) merge - but ignore certain commits?

["Peter Valdemar Mørch (Lists)"]

Hi,

I'm wondering how to merge a branch back to a master/svn trunk, getting 
"almost" all the commits on the branch. I've experimented with "git 
merge -s ours" unsuccessfully and don't know how else to proceed.

Background: Our svn trunk has had many solid commits, and a few that 
aren't ready yet. We need to make a new release without these unready 
commits but with some new functionality.

Externally to git, a branch was made off of trunk's HEAD. Call it 
"newbranch".

The idea is to:

* Create a git branch off of svn "newbranch", call it "gitnewbranch".

* "git revert" the "few unready" commits on "gitnewbranch" so we have a 
solid foundation

* add the new functionality to "gitnewbranch"

* "git svn dcommit" to get the new functionality on svn's "newbranch"

* And now the trick: "git merge" "gitnewbranch" back to master. But I 
want to avoid the "git revert" of the few commits that weren't ready yet.

* "git svn dcommit" master to get the new functionality into svn trunk.

How do I "git merge" all of "gitnewbranch" except the reverts?

I tried doing just the revert step, and then
"git merge -s ours gitnewbranch"
on master, and that seemed to work. Annoyingly (to me :-D) "git log 
master" does show the reverts that happened on gitnewbranch, but the 
files in master were not changed. However, when I "git svn rebase", it 
fails with a
"CONFLICT (content): Merge conflict in <file>".
And hence, "git svn dcommit" fails too.

Is there a way to "git merge gitnewbranch" excluding the reverts, just 
the "new functionality", so the log of master doesn't even mention the 
reverts and so "git svn rebase" and "git svn dcommit" work properly?

I guess I could git cherry-pick all the "new functionality" commits from 
gitnewbranch to master, but it sort of defeats the coolness of gits 
branch handling if I have to keep track of the cherry-picked commits 
manually.

How do I do this "properly"?

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

Re: Git (svn) merge - but ignore certain commits?

[Peter Harris]

On Sat, Dec 27, 2008 at 8:02 AM, "Peter Valdemar Mørch (Lists)" wrote:
>
> * And now the trick: "git merge" "gitnewbranch" back to master. But I want
> to avoid the "git revert" of the few commits that weren't ready yet.
>
> * "git svn dcommit" master to get the new functionality into svn trunk.
>
> How do I "git merge" all of "gitnewbranch" except the reverts?

"git rebase -i trunk" after you "git merge". Delete the lines that
contain the will-be-reverted commits and the revert commits. Actually,
skip the reverts in the first place to save time.

Normally I wouldn't suggest it, since it will throw away your merge,
but "git svn dcommit" does an implicit rebase anyway, so you will lose
nothing.

> Is there a way to "git merge gitnewbranch" excluding the reverts, just the
> "new functionality", so the log of master doesn't even mention the reverts
> and so "git svn rebase" and "git svn dcommit" work properly?

If your branch is so ugly that you want to toss many of the commits
anyway, maybe "git merge --squash" is what you are looking for? Or
maybe you want to "git rebase -i" before merging?

> How do I do this "properly"?

Use many short-lived feature branches, not few long-lived generic
"development" branches. Merge-and-delete is easier than herding
reverts.

Peter Harris

Re: Git (svn) merge - but ignore certain commits?

["Peter Valdemar Mørch (Lists)"]

First, a well-overdue thanks to Peter for your post.

Peter Harris git-at-peter.is-a-geek.org |Lists| wrote:
> If your branch is so ugly that you want to toss many of the commits
> anyway, maybe "git merge --squash" is what you are looking for? Or
> maybe you want to "git rebase -i" before merging?

It isn't. The whole reason for the branch was that there were 4 
"beta-level" commits on trunk/master along with a whole bunch of good 
stuff. And we wanted to add a little more good stuff, exclude the beta 
stuff and create a release.

>> How do I do this "properly"?
> 
> Use many short-lived feature branches, not few long-lived generic
> "development" branches. Merge-and-delete is easier than herding
> reverts.

I don't understand this, I'm affraid. Our "newbranch" was very short 
lived. 4 reverts and 5 commits.

What I ended up doing was to create two git branches off of svn 
"newbranch": One with all the fixes but without the reverts, and one 
with just the reverts. Do all the development on the one with the fixes, 
and then "git merge" them to both master and "gitnewbranch", then one 
with the reverts. And then git svn dcommit them both.

However *the* problem was with repeated merges: I later discovered a 
problem on the branch and need to add a commit for it to both master and 
newbranch/gitnewbranch. Aside from git cherry-pick (where I take care of 
the repeated merge problem) I still haven't found a good solution.

I ended up using git cherry-pick, and diff and patch / git diff and git 
apply. Sub-optimal. :-( But small commits! :-)

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

Re: Git (svn) merge - but ignore certain commits?

[Peter Harris]

On Thu, Jan 8, 2009 at 12:49 PM, "Peter Valdemar Mørch (Lists)" wrote:
>
> However *the* problem was with repeated merges: I later discovered a problem
> on the branch and need to add a commit for it to both master and
> newbranch/gitnewbranch. Aside from git cherry-pick (where I take care of the
> repeated merge problem) I still haven't found a good solution.

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.

Peter Harris

Re: Git (svn) merge - but ignore certain commits?

["Peter Valdemar Mørch (Lists)"]

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

Re: Git (svn) merge - but ignore certain commits?

[Peter Harris]

On Thu, Jan 8, 2009 at 2:17 PM, "Peter Valdemar Mørch (Lists)" wrote:
>
> 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).

Stop and think about that for a second.

Rephrased, "I want to cherry pick a few commits to master using the
merge command".

That sounds rather silly when I put it that way. What do you really want? Hmm.

Maybe you want to cherry pick those commits. Maybe (if this is still
an unpublished branch), you want to "git rebase --onto B E" your
branch to get the non-dirty version of E, then merge.

Or maybe you do want to merge, but you're getting confused by not
seeing the automatic conflict markers. You could merge --no-commit the
branch, fix the conflicts (E conflicts logically with B, even if 'git
merge' doesn't automatically mark it as such -- 'git revert -n E' may
even do most of the work), and only then commit the merge revision.
Repeated merges from this state will not keep trying to import E
(since E is already in the history).

Peter Harris