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).

3 Answers
3

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?

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...
–
JefromiMay 7 '10 at 5:02

I'm changing a database config file on the branch, right after the branch point, and don't want to merge this back to master. Later bug fixes on the branch though, I do want to merge back to master. This will allow that, without cherry-picking the fix commits individually.
–
Dave CameronJan 20 '13 at 16:57

While doing the above, it occurred to me that this database information really belongs in environment variables, as in the Twelve-Factor App.
–
Dave CameronJan 20 '13 at 17:11

An example where I need this: - team working in main and DevBranch needs me to build a feature - I build said feature, merge it into both main and DevBranch - Later, it is discovered that what I built subtly misbehaves without other stuff currently only available on DevBranch - I need to back my change out of main, but I want ultimately a state where later DevBranch can be merged into main and my feature will then be back in - solution: create DevB2 from the last "main" commit merged to DevBranch. Revert my feature on DevB2, merge (normally) into main and with --strategy=ours into DevBranch
–
Daniel MartinFeb 23 '13 at 3:57

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.