0

Is there a way to avoid some part of a file to be ignored while merging branches,

i.e. config.ini (just invented), suppose that I can't make config.dev.ini, config.test.ini and in all branches I only have config.ini file.

and in config.ini we have 'environment= dev/test/prod1..' one of it.

Every time merging from dev to test/master there is a conflict occur on config.ini and showing environment changed as dev or test or.. based on source branch.

Is there a way to ignore that part from conflict detection but keep other lines still in consideration. Is my question against SCM foundations? We're able to ignore files totally, why not partially?

I don't wanna put it in .gitignore.I just gave this config.ini thing as an example. However, there are some parts in some files I'm trying to avoid other developers overwrite it. Without ignoring the file totally. Of course for config.ini a programtic solution can be produced but I wondered existence of a solution for such cases in general.

Davut Gürbüz
  • 5,526
  • 4
  • 47
  • 83
  • There's a lot of ways of managing deployment/build targets, but Git is not a deployment tool. Track the instructions for how to build your deployment in the source, build whichever one you want when it's time to deploy. – jthill Nov 29 '20 at 21:38
  • @jthill we use Jenkins as build tool and we already have these alterations while build/deploy. However, overwriting default option by mistake and manually building from developer PC is still a risk. I just sought for a possible workaround if any as stated in the question. – Davut Gürbüz Nov 30 '20 at 06:25
  • Why would you put an individual developer's choice of build target or any other deployment/build option in a tracked file? Don't track local choices, track how to respond to them. Put local deployment/build choices someplace local. – jthill Nov 30 '20 at 07:38
  • @jthill see, it's not individual build option, it's the default deployment setting. To be more precise in java maven project there is an option to push a snapshot to local nexus repository. (Normally we overwrite in Jenkins pipeline). If setting contains `-SNAPSHOT` reserved keyword artifact goes to snapshots repo, so this must be stored in pom.xml in dev branch only. if it's removed by mistake and developer deploy from it's local -by considering he's pushing artifact to a dev repo- it can go to release! As you suggested developer own options like `.pref` files we already ignore. – Davut Gürbüz Nov 30 '20 at 08:40
  • Another thing, I resolve that part before while resolving conflict. Why it's repeating again for every merge. it must be clear I don't want that part in that branch. – Davut Gürbüz Nov 30 '20 at 08:52
  • A setting that varies depending on why you're building is a build option. If this one is unlike other things you regard as "individual build options", fine, but what that setting's value isn't is part of your source. It's a build option. – jthill Nov 30 '20 at 18:14
  • @jthill I am not ignoring that it's a build option. However that version build option and dependencies must be stored in the same pom.xml file. I would like to merge dependencies but not that build option part. It is part of build configuration. In dev branch I would like to keep default version as 1.0.0-SNAPSHOT, rest of the file need to be merged, because new dependencies might be added to system. – Davut Gürbüz Nov 30 '20 at 19:06
  • I'd recommend the first paragraph of [this answer](https://stackoverflow.com/a/57685306/1290731) to the linked dup. – jthill Nov 30 '20 at 19:18

1 Answers1

2

No, there isn't a way to do this easily. You can use a custom merge driver and wire it up in .gitattributes, but that will mean you have to write a custom merge implementation and ask every user to install it on their system, which is a hassle, and it's also not going to be used by any hosting platform you use.

This has been asked on the Git list, and the answer is essentially, “Don't do that.” What you're asking for is similar to the Git FAQ question on why you can't ignore changes to tracked files, but more generally, the answer is that you should do one of the following:

  • Use different files and copy one of them into an ignored location using a script, depending on the environment.
  • Generate the config file from a template on each system using a script.
  • Use configuration from the environment, which is a best practice anyway.
bk2204
  • 64,793
  • 6
  • 84
  • 100