4

i am looking for a merge strategy which allows me to choose both changes from my branch as well as the incoming changes.

Tried searching through different threads but could not figure out how to do this.

So i have multiple branches in my repo. I need to merge every branch to local master and then to remote pending approval from code reviewer. To achieve this I do a rebase from master first and then a fast forward merge into master, the standard workflow. the code consists of mostly config files and these multiple branches have code changes at very same place (like adding of a new parameter) these parameters are never same but are at same location. git triggers them as conflicts but all I wanted it to do is just select both my changes in the branch as well as those coming in from master during rebase. I know the risks involved but i have a validation script which can detect duplicates and alert me on anomalies.

So ultimate goal is to script these merges and intervene only if the validation script fails.

thanks for the replies

manusR
  • 51
  • 2
  • 4
  • Where are the changes coming from? Do you have them fetched locally?Can't you just merge from the incoming branch into yours? – grw Oct 05 '11 at 10:09
  • Could you show an example of what you want to accomplish, and explain why you want to do that? – svick Oct 05 '11 at 10:17
  • 1
    If you actually hit conflicts that you know you can resolve by taking one version or the other, you can use `git checkout --ours `, but it's not clear to me you're actually in that situation. – Cascabel Oct 05 '11 at 22:40
  • @Jefromi yes I do get conflicts and instead of choosing either of one version i want to choose both versions. i.e conflicting lines after merge will include both the lines from ours and theirs. – manusR Oct 05 '11 at 23:56
  • So just remove all the conflict markers, if that's what you want. – Cascabel Oct 06 '11 at 07:44
  • that's right finally i ended up doing the same. i was looking for some merger strategy/options to do it for me :) – manusR Oct 06 '11 at 21:25

1 Answers1

1

The default merge algorithm (with its various strategies) should by default keep both your changes and the incoming changes.
As described in "How does Git solve the merging problem?",

The important part of a merge is not how it handles conflicts (which need to be verified by a human anyway if they are at all interesting), but that it should meld the history together right so that you have a new solid base for future merges.

In other words, the important part is the trivial part: the naming of the parents, and keeping track of their relationship. Not the clashes.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250