0

A portion of project code is generated, yet it must be tracked since regenerating this portion requires lots of resources(mostly time).

On master branch, commits are performed when this portion of code is change just to isolate those changes.

On topic branches the same portion of code can be regenerated.

Yet when merging topic branches this portion of code must not be altered by the changes in topic branch, files on master branch must remain untouched.

I have tried to use .gitattribute to set merge=ours strategy yet this is just for when there are conflicts as is stated in documentation.

The merge constraint should be applied without manual intervention. since its easy to forget.

qt-x
  • 133
  • 1
  • 9
  • Have you tried this approach, where you manually pick what you want to merge? [link](https://stackoverflow.com/questions/18115411/how-to-merge-specific-files-from-git-branches) – mnestorov Aug 29 '19 at 11:49

2 Answers2

2

Git does not provide a way to automate this.

You could write your own code to do it. Note in particular that if you run:

git merge -s qt-x somebranch

your Git will invoke whatever command it finds on your $PATH that is named:

git-merge-qt-x

This program, which you will have to write, has to do the same thing that git-merge-recursive, git-merge-octopus, git-merge-ours, git-merge-subtree, and git-merge-resolve all do. This job is complicated. You can, however, inspect the source code to Git, including that for git-merge-resolve and git-merge-octopus. These will give you some idea of how to start.

The problem with using either of these as a template is that they rely on git read-tree to do most of their work, and it's git read-tree that is causing your problem: if there is a single merge base, and read-tree sees that file F is unchanged from base to tip#1 but changed from base to tip#2, read-tree simply takes F from tip#2, even if you didn't want it to. Your best bet will probably be to invoke git read-tree anyway and then correct the result for specific files.

(You also lose the ability to do recursive merges, unless you write quite a lot of code, but it should be easy, after reading the two scripts, to detect the case where a recursive merge is called-for.)

Consider also scripting around git merge --no-commit, as in EncryptedWatermelon's answer.

torek
  • 448,244
  • 59
  • 642
  • 775
0

I had to do something similar to this not long ago. Merge the branch without committing merge and revert individual files. It's tedious but if you have a list of files saved it's not so bad for future merges.

git merge branch_foo --no-commit
git checkout HEAD file1 file2 file3
git add -u
git merge --continue

Edit: Changed git add line based on input from @knittl

EncryptedWatermelon
  • 4,788
  • 1
  • 12
  • 28
  • I forgot to mention _automatically_ . But it is a start, if i can do this in a merge strategy script. – qt-x Aug 29 '19 at 12:51
  • Avoid `add .` (it will add files which you do not want to add). Either add the files explicitly or use `add -u` – knittl Aug 29 '19 at 12:58
  • @knittl Is the best answer thus far even with the bad habit of `git add .` – qt-x Aug 29 '19 at 13:38
  • @qt-x - the idea of automating this in a merge strategy script won't work, for the same reason that my other answer doesn't actually work. The trouble is convincing git that the files need to be merged in the first place, and if only one side has changes then git won't think so – Mark Adelsberger Aug 29 '19 at 13:51
  • @MarkAdelsberger that is exactly the issue: How to prevent a merge for files that git thinks there is no need to check for merge conflict. The conflict is semantically more than syntactically. – qt-x Aug 29 '19 at 14:10
  • 1
    @qt-x - No; until git thinks they have to be merged, it's just going to copy the version that's modified. You WANT it to think a merge is needed, and then you want it to do the merge by keeping the master copy. – Mark Adelsberger Aug 29 '19 at 21:01