0

The setup

I have a repository for a project; let's call it foo. I have a particular file in the repository; let's call it bar. I have two branches in foo; master for development and public for stable releases.

The workflow

I make changes in master, test them right there, and if they survive the tests, merge them into public. Assume I am currently working with bar, a program that shows visual content on the screen, and takes a specific amount of time to run. To cut the runtime during testing, I usually adjust a couple of parameters so it won't run for the complete duration, but only a partial amount.

The problem

There are many changes I make in master that I would like public to reflect; however, in master, I don't want to have to change all the parameters back to the default user-facing ones right before (or after) I merge. I know [1] the lines at which these parameters exist, and, optionally, [2] a list regex patterns, one of which these lines would match.

Is there a way I can configure git-merge for this particular repository to merge always as ours for those particular lines, so that my parameters and configurations don't get overwritten?

axolotl
  • 1,042
  • 1
  • 12
  • 23
  • You can probably simulate something like this by renaming the old master file to something new in a new branch, and renaming your new changes to have that same new file then merging. In the git conflict you can probably accept yours and theirs selectively how you want. – Tyler S. Loeper Jul 16 '18 at 14:37
  • If you want branch-specific content, a post-checkout hook to construct it is probably most convenient, see [here](https://stackoverflow.com/questions/20078756/making-git-retain-different-section-content-between-branches/20087076#20087076) for an example – jthill Jul 16 '18 at 14:37
  • 1
    In your question, I read that foo is 1) a repository (or maybe a project?) 2) a file 3) a program. Get your terms straight and stick to them or it'll be very hard to communicate. I'll assume foo is just your repo, in which case its name is here irrelevant. – Romain Valeri Jul 16 '18 at 15:44

1 Answers1

1

This is really a variation on "can I omit some changes from a merge", which is generally asked with the intent of keeping configuration for a different environment on each branch (which is also basically what this question boils down to).

Tools that decide how to manage a merge based on line numbers or a regex will end up having to make assumptions, and it would be hard for generic tooling to validate those assumptions. For that reason, I think it's reasonable that git itself doesn't try to support such a feature. If you know that such assumptions hold for you, then you could write a merge driver that does what you want.

It will be much easier - and less fragile - if you can arrange things so that changes you want to merge are never in the same file as changes you don't want to merge. Then your custom merge driver can just run a no-op like the true command, and .gitattributes can be used to specify that merge driver for those files whose changes you don't want to merge. (Similarly-motivated example can be found at http://www.mcclellandlegge.com/2017-03-20-customgitmergedriver/ - unless of course the link dies). With build tooling, this could be arranged.[1]

Of course, once you have those techniques in play, there's not necessarily any reason to tie the choice of config to the branch. You could have a "dev config file" and a "prod config file", and specify the correct one for each build (or each run). It may even be sensible to not keep the config files in source control at that point.

--

[1] Suppose you have a file that contains changes you want to merge, and changes you don't want to merge. You would put placeholders in for the changes you don't want to merge, and the real values go in, say, a env-config.txt file. So your build knows how to read env-config.txt and substitute the values it finds there for the placeholders, and then you just don't merge env-config.txt across branches at all.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52