2

I have 20 files in my repository foo1.c,foo2.c,...foo20.c I am working on foo2.c

Now whenever I do a git pull it pulls in and merges changes to all foo*.c including foo2.c I would like to prevent automatic merging of files that are modified in my repository.

For example someone might have added x=20 at the some location in the file which overrides my modification of x=0 at the top of the file.

Doing a automatic merge of Bob's changes with my changes can lead to hard to detect errors and if one of these errors has a potential of randomly rebooting the mars rover, I would prefer to manually review each change before I merge it.

So with this background I would like to know if there is a way for me to pull(fetch+merge) files that are not modified in my repo and only fetch changes which affect the files I am modifying so that I can do a manual diff+merge

vijayvithal
  • 551
  • 1
  • 5
  • 13
  • Found the answer on http://stackoverflow.com/questions/3122056/how-to-get-3-way-merge-in-git-on-non-conflict-merges – vijayvithal Feb 27 '13 at 07:46

3 Answers3

1

You could specify in a .gitattributes file that you want your version of foo2.c to be the one considered during merge:

foo2.c merge=ours

(from the gitattributes page. You need to activate that driver though)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 5 years later I think you are still around, and I'm interested in your opinion on what I think are the consequences of doing what you suggest. I came here because one of us performed a merge from master into his story branch using TortoiseGit; he clicked away the warning and unchecked many files in Tortoise's merge dialog. Consequently what git registered as the merge result was in many cases his old file versions. master changes were effectively discarded and effectively reverted when that story was eventually merged back to master. – Peter - Reinstate Monica Jul 11 '18 at 14:32
  • See https://randyfay.com/content/avoiding-git-disasters-gory-story, part 2, for a detailed description of that. Now I suppose that setting "merge=ours" has the same consequences for the named files, i.e. changes on master which happened between branching off and merging master into story will be reverted on master when merging the story back. Is that right? (That would usually neither be intended nor good, I suppose.) – Peter - Reinstate Monica Jul 11 '18 at 14:35
  • @PeterA.Schneider I am *always* around ;) (https://meta.stackexchange.com/q/122976/6309). Yes, a merge back to master would mean keeping master version (ours). So that setting needs to be temporary, just for the time you actually need it. – VonC Jul 11 '18 at 15:03
  • What I mean is that *anybody else* merging such a story branch back to master (after it was pushed, obviously) would revert all changes of foo2.c made on master between the branching-off of *story* and that merge of master into *story* with "merge=ours". (At least, that's what I suppose and would like your opinion on.) That's @vonbrand's objection. Silently losing master changes is supposedly not what the OP wants. (The answer mentioned below the post -- unset the merge attribute, leading to a conflict -- seems less dangerous.) – Peter - Reinstate Monica Jul 11 '18 at 16:50
  • @PeterA.Schneider yes, that is the risk. At some point, this becomes less about the tool, and more about the collaboration and process around it. I always prefer doing a rebase before a merge, if I am the only one working on a pr/fix/story branch. – VonC Jul 11 '18 at 20:25
1
  1. don't use global variables.
  2. use code review rather than doing this..
  3. or in the worst case, you can do a git diff and see what bob has changed...
zzk
  • 1,347
  • 9
  • 15
  • I agree with #1 On #2 The original question was to enable incremental code review. for my team a git pull can pullin changes to 100's of files and the notification that some files were merged can get lost in the "noise" so I am looking for a method to always force a conflict if the file was changed locally and on the server. for e.g. my current version control system gives a error message "merge required: File was changed locally and on the server" and leaves it to the user to do a diff+merge and pulls the remaining changes. I did not understand #3 can you please elaborate. – vijayvithal Feb 27 '13 at 07:38
  • Work on local branches, only push when ready. Have a gatekeeper who integrates Alice's, Bob's and Charlie's pùblished branches into the official, published branch. Rinse and repeat. – vonbrand Feb 27 '13 at 20:07
1

Do work on a local branch, only pull into the official branches, merge/rebase your changes on the respective official (published) branch when ready, push the result upstream. No "Bob's changes merged into Alice's halfway finished work messed everything up, and Charlie from QA blew a gasket".

vonbrand
  • 11,412
  • 8
  • 32
  • 52
  • 1
    I agree, your answer is better than mine (which was just about avoiding the merge, without thinking about the bigger picture). So, +1. – VonC Feb 27 '13 at 19:48