4

Hi I have a git file that I do not want changes to be merged into it, instead, I want changes to be always appending to the end of the file, while the rest of the project files are merging as normal. Is this configurable in git?

e.g. In the upstream a file F has one line

1. |10-09-2016 00:12:43 : Check completed

In my fork, I changed F to

1. |11-09-2016 00:10:55 : Check completed

Then I submit my change and create a MR from my fork to the upstream.

Instead of changing the file F on upsteam to

1. |11-09-2016 00:10:55 : Check completed

I want the file F on upsteam, after accepting the MR, to become

1. |10-09-2016 00:12:43 : Check completed
2. |11-09-2016 00:10:55 : Check completed
user1589188
  • 5,316
  • 17
  • 67
  • 130
  • I would just change the way you write to that file F so that writes are appended to it, then commit that change. – Kyle Falconer Sep 14 '16 at 01:32
  • Yes thats doable but won't work when you have multiple people on the project. – user1589188 Sep 14 '16 at 01:35
  • That depends on how this file is written. – Kyle Falconer Sep 14 '16 at 01:40
  • That piqued my interest, how is it depended? – user1589188 Sep 14 '16 at 02:59
  • Say this file is generated by a script that runs a program and redirects its output to a file, like `$ some_program.sh > F`. Instead of doing `>`, you might do `>>` which "appends" instead of "writes" (which erases and writes the content to the file). Another example is if this file is written by a program you've written, instead of doing "write" mode, use "append" mode. Here's an example of how to do that in Python: http://stackoverflow.com/a/4706519/940217 – Kyle Falconer Sep 14 '16 at 03:04
  • Ah ok. I guess the difficult part is not how the file is written. Say I and another dev both check out. Now I append before check in. The other dev also append before check in, but this dev will not have my changes yet. At the end of our check-ins, the upstream will still only have either one of the versions depending on who check in last. – user1589188 Sep 14 '16 at 03:23
  • What you are describing there is a classic merge conflict, which is resolved [just like any other merge conflict](http://stackoverflow.com/q/161813/940217). Essentially, one dev initiates the merge, edits the file with the conflicts so that both changes are preserved, then another commit is made with the resolved conflict. – Kyle Falconer Sep 14 '16 at 03:27
  • 1
    Yes you are right, essentially the issue is to avoid merge conflict. But due to the nature of this file F, I can allow "always appending" as the default way to resolve merge conflict. Since this file is updated often, I want to avoid frequent merge conflicts by telling git to do append for this file as default behaviour, hence this SO question. – user1589188 Sep 14 '16 at 03:37

1 Answers1

2

You can try and define a custom merge manager, which will aggregates the two versions in the case of a merge conflict.

You can see a full example here: "strategy for git and append-mostly files"

You will also see alternatives for you to try, like adding in a .gitattributes:

 myfile merge=union

No merge driver needed in that case.

union

Run 3-way file level merge for text files, but take lines from both versions, instead of leaving conflict markers.
This tends to leave the added lines in the resulting file in random order and the user should verify the result. Do not use this if you do not understand the implications.

(That is not "appending" the other version though)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250