How to prevent git merge to merge a specific file from trunk into a branch and vice versa

Question

Hi, I am using git while developing VHDL code. I am doing development on a component in a git branch: comp_dev. The component interface does not change, just the code inside the component. Now, this component already exists in the master branch, but in a more stable version, enough for other developers to be able to use the component. The other developers also have branches for their work, and when their code is good they merge their branches back to master.

At this stage I need to be able to merge all the changes from master back to my comp_dev branch, which is basically no problem, but sometimes the stable version of the component I am working on do change as a part of other designers work, but not the interface. I have to do manual git merge -s ours on that particular file every time I want to merge, otherwise I get a conflict that I need to solve manually, throwing out their work.

The same happens if I want to merge changes in other files back to master. If I forget to do git merge -s ours src/rx/state_machine.vhd comp_dev before I do a git merge, then I end up with either a manual merge, or I accidentally merge an unstable version of the state machine on top of the stable one.

Is there a way to temporarily exclude one file from merges?

Answer 1

If I understand correctly, you want to defer having to merge changes to the said component (let's name it 'C') while the focus of your work is on some other module. A side effect of your work are minor changes to 'C', which happen to conflict with other people's work, but you don't want the hassle of also merging 'C' every time you push your focus work to wherever your 'master' is.

AFAIK, a change set in git is atomic and does not know about files; so there is no way to exclude a file from merge, short of resolving the merge conflict in favor of the revision you prefer.

There may be another way out of your situation though.

You probably want to factor 'C' out into a separate library, and have a separate git repository for it. Your project will be split into multiple repositories. But fear not, git will let you manage this through submodules. Check out http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html for the details on how to do so.

Submodules will allow you to check out a given revision of 'C', and focus your work on a different part of the source. You can then edit, commit, and merge your work independently of the changes anyone has made to 'C'.

Concerning the management of concurrent changes, the usual stance with open-source version control is that VC is not a substitute for communicating with the team members. Agree on the general development approach, minimize concurrent incompatible changes, and the development process will become less of a pain.

Answer 2

I've been chatting this up a bit with some friends, and I thought I'd share in case you find it useful.

rebase and merge might not be too useful for what you're trying to do. A safer, easier, boring, and otherwise more predictable approach to only fetching certain bits of code or certain files would be using git-provided methods for manually moving patches, like (a) cherry picking individual commits or (b) format-patch and am. If you need to tweak the result (like deleting a file), do so and explain why in a new commit. Or just tweak stuff while you're cherry picking or applying patches. am can be --interactive, and a cherry-pick can be modified with a commit --amend.

I tried another tack with a long-standing branch: merge everything, then manually revert the stuff I really didn't want merged. This worked fine too.

Something else that seems like a great idea is using fine-grained branches.

I guess I feel like one key take-home message is that paying attention to the code and having good automated tests that are run frequently is more important than mastering a particular git patch/merge strategy.

Answer 3

I posted a solution that works for me here