-1

I have a AssemblyInfo.cs file that specifies the version of the software that is built on that branch (lets call it "branch_1.0.0").

If a patch branch "branch_1.0.1" is cut from "branch_1.0.0" how can i prevent the AssemblyInfo.cs file from being changed when "branch_1.0.1" is merged back into a different branch (e.g "branch_1.0.0").

I have tried using git attributes to specify a merge driver (git config --global merge.ours.driver true) but i still see the file updated when i don't want it be

Thats method seems only of use if there is a merge conflict - i want to make sure the file is not overwritten at all during a merge.

Is there a simple solution to this issue that im missing? Thanks

donal
  • 163
  • 2
  • 4
  • 13
  • 1
    Possible duplicate of [Git - Ignore files during merge](https://stackoverflow.com/questions/15232000/git-ignore-files-during-merge) – chemicalcrux Jun 29 '18 at 14:41
  • Thanks @chemicalcrux .The answer sems like it would work but seems labourious and error prone - some developers may forget to do that on each commit. is there a way of automating it? – donal Jun 29 '18 at 14:47
  • You might be able to add a hook that fires when someone tries to merge. The hook would abort the merge, do a no-commit merge instead, unstage the file, and then commit. – chemicalcrux Jun 29 '18 at 14:52
  • 1
    The short answer is *no, there is no way to do this in Git* (because the `.gitattributes` merge driver trick only works in some cases, as I noted in a comment on the linked question). Your best bet in general is not to commit such files at all—leave them untracked (and probably ignored as well) and generate them automatically instead, using some information that *is* tracked/committed but survives merges. – torek Jun 29 '18 at 15:02

1 Answers1

0

If "branch_1.0.1" has made a change to AssemblyInfo.cs but you haven't commited it yet, you could try stashing your changes, merging 1.0.1 into 1.0.0, then unstashing and resolving the unstashed changes.

However, you shouldn't normally have problems when merging your 1.0.1 branch into 1.0.0 if 1.0.1 was started from 1.0.0 and 1.0.0 didn't get any other changes since then.

If 1.0.0 DID get changes before your 1.0.1 (which shouldn't happen normally), you should be able to resolve conflicts during merge. Are you sure you're not skipping through that?

Regardless, I would suggest you visualize your Git branches with a GUI so you could clearly understand how your commits are being applied into your base branch, because this isn't normal behavior.

fdrobidoux
  • 274
  • 4
  • 11