Menu
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.. ?
968
Sync merge is used when you want to fetch all of the latest changes made on your parent branch (e.g. trunk). Using this will keep your feature branch up-to-date with the parent branch.
Git merging combines sequences of commits into one unified history of commits. There are two main ways Git will merge: Fast Forward and Three way. Git can automatically merge commits unless there are changes that conflict in both commit sequences.
Recursive. This operates on two heads. Recursive is the default merge strategy when pulling or merging one branch. Additionally this can detect and handle merges involving renames, but currently cannot make use of detected copies.
Instead, Git uses an algorithm to determine what bits of a file have changed and if any of those bits could represent a conflict. For simple text files, Git uses an approach known as the longest common subsequence algorithm to perform merges and to detect merge conflicts.
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?
64
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
