tags:

views:

38

answers:

3

I have a repo where 'master' is going in a certain direction, and a second branch 'foo' is going to be divergent for a couple of commits, then track all subsequent changes to 'master' after that. This is all by choice of course.

In Subversion you could do a --record-only merge to mark things as "merge has happened" even though no actual changes were committed. i.e. this change the merge-tracking numbers in properties attached to directories in the target branch.

I have had a play with..

git merge --no-commit master

.. as something I may be able to tinker with before I do the commit, but it is making a hell of a mess of the target branch for part of the change in question (rename followed by delete).

There must be an easier way.. ?

  • Paul
+1  A: 

Is this what you're looking for?

git merge --strategy=ours master

ours

This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches.

This seems to be what you're asking for - it creates a merge commit which doesn't actually introduce any changes.

But do you really want to do this? Is there some reason you can't just have the branches actually diverge (without a merge happening) then merge later?

Jefromi
P.S. I swear this is the third time I've mentioned `--strategy=ours` in the last week. I wonder why everyone suddenly needs to throw away history...
Jefromi
A: 

Paul, git handles rename followed by delete with (relative to svn) ease. It tracks content not filename. In svn this would be painful, what problems are your experiencing with git while doing this?

Justin
A: 

jefromi nailed it. Here's the real thing - http://github.com/jbehave/jbehave-core/blob/master/examples/trader/src/main/java/org/jbehave/examples/trader/TraderStory.java (play with switch branches and look at line 65).

This was not so much about 'throwing away history', but more about using Git to juggle divergent changes from a single base. In order to get folks to adopt JBehave (IMO) we need to make examples really easy to follow. Before this 'Trader' example had JBehave vanilla + a Guice variant + a SpringFramework variant + a PicoContainer variant all in the same source directory. Now, four branches can illustrate the most canonical representations of the 'Trader' example.

-ph

Paul Hammant