0

Lets say I have an origin called myorigin and a clone called myclone. I want to keep myclone updated with myorigin changes. In myorigin I have a file which content is:

Name: myorigin
some text
some more text

and after cloning I modify this file in myclone as follows:

Name: myclone
some text
some more text

When in myclone I do:

git fetch
git merge origin

it will tell me there are conflicts.

Is there any way to tell git to ignore certain lines?

Should I approach it differently?

Alvaro
  • 9,247
  • 8
  • 49
  • 76
  • A conflict is a situation when changes on the merged branches cannot be safely combined, usually because they modify the same line(s) or are contradictory. The human intervention is required in order to solve the conflict. The human can decide to keep one of the two versions and discard the other or to manually combine the changes from both branches. – axiac Jan 10 '17 at 20:41
  • @axiac Thanks. But I would have to manually accept one of the two versions every time I merge, I wondered if there was some way of doing it, kind of like how ! works for js comments, or some other approach. – Alvaro Jan 10 '17 at 20:58
  • If you get conflicts on every merge then the problem is somewhere else. Maybe the file should not be put in the repository, in the first place. Is it a configuration file or why do you get conflicts on every merge? – axiac Jan 10 '17 at 21:08
  • @axiac I'm trying to figure out a way to handle a framework and create other repositories based on it, you can see exactly what I intend from [this question](https://stackoverflow.com/questions/41321414). But I guess Ill have to keep things separate. Thanks :) – Alvaro Jan 10 '17 at 21:10

1 Answers1

3

You can write your own merge drivers, or write a set of clean and smudge filters, so that Git doesn't do this merge, or doesn't see this line. But in general, no, there is no simple way to do what you are suggesting.

As a general rule, any sort of "configuration" data should not be committed to the source repository itself. Instead, if it's appropriate, the source repository should contain a sample configuration, and the actual configuration is kept elsewhere (either .gitignore-d, or outside of the work-tree entirely).

If configurations need to be upgraded when the user goes from "FooBarix Version 1.3" to "FooBarix Version 2.0", the 2.0 version should probably include a configuration-migration program that gets run during the upgrade, saving the original configuration and switching to a new configuration (none of which are source-controlled as part of FooBarix itself). This also provides the ability to downgrade the configuration, should it prove necessary to back out of 2.0 back to 1.3.

torek
  • 448,244
  • 59
  • 642
  • 775