0

I have an XML file that we consider binary in git. This file is externally modified and committed.

I don't care about who edited it and what's new in the file. I just want to have the latest file version at every pull. At this time, at every git pull I have a merge conflict.

I just want that this file is overwritten on every git pull, without manually doing stuff like git fetch/checkout/reset every time I have to sync my repo.

Careful: I want to overwrite just that file, not every file.

Thanks

Ivan Morgillo
  • 2,837
  • 4
  • 30
  • 46
  • I wonder how you get into that situation. It seems like you are not using git quite correctly here. Can you give us some details on your situation – maybe there is a way simpler solution. – Chronial Dec 21 '12 at 13:30
  • Sure! Three developers working on iOS app. Every time one of us open the storyboard, the funny Xcode edits it, even if I don't do any actual edit. It just "updates" some lines. Looking for answers on SO, we realized we had to manage it as a binary file and git could avoid merge conflicts for every commit. At the moment, at every commit we have to discard edits of the "untouched storyboard" and commit the actual files we edited. – Ivan Morgillo Dec 21 '12 at 14:57

3 Answers3

0

I thought you could use Git Hooks, but I don't see one running before a pull...

A possible workaround would be to make a script to delete this file and chain with the needed git pull...

PhiLho
  • 40,535
  • 6
  • 96
  • 134
0

This answer shows how to always select the local version for conflicted merges on a specific file. However, midway through the answer, the author describes also how to always use the remote version.

Essentially, you have to use git attributes to specify a specific merge driver for that specific file, with:

echo binaryfile.xml merge=keepTheirs > dir/with/binary/file/.gitattributes
git config merge.keepTheirs.name "always keep their file during merge"
git config merge.keepTheirs.driver "keepTheirs.sh %O %A %B"
git add -A
git commit -m "commit file for git attributes"

and then create keepTheirs.sh in your $PATH:

cp -f "$3" "$2"
exit 0

Please refer to that answer for a detailed explanation.

Community
  • 1
  • 1
Marco Leogrande
  • 8,050
  • 4
  • 30
  • 48
0

If the changes to your files are not actual changes, you should not submit them. This will clutter your version history and cause numerous problems.

From your statement I’m not quite sure which is the case, but there are 2 possibilities:

  1. The file in question is a local storage file, the contents of which are not relevant for your actual sourcecode. In this case the file should be part of your .gitignore.

  2. This file is actually part of your source and will thus have relevant changes in the future. By setting up the merge settings like you are planning to do, you will cause trouble once this file actually changes. Because merges will then be destructive.

    In this case the solution is a little bit more complicated (apart from getting a fix for the crappy tool that changes stuff it doesn’t actually change …). What you are probably looking for is the assume unchanged functionality of git. You can access it with this command:

    git update-index --assume-unchanged <file>
    

    git docu (git help update-index):

    You can set "assume unchanged" bit to paths you have not changed to cause git not to do this check. Note that setting this bit on a path does not mean git will check the contents of the file to see if it has changed — it makes git to omit any checking and assume it has not changed. When you make changes to working tree files, you have to explicitly tell git about it by dropping "assume unchanged" bit, either before or after you modify them.

Chronial
  • 66,706
  • 14
  • 93
  • 99
  • I need that file. Randomly one of us works on that file, saves it, commits it and pushes it. When the other two try to `git pull` on a clean local repo, they realize there is a "modified file", the storyboard, just because they are viewing that file. I want to `git pull` and automatically discard those changes I didn't actually committed. – Ivan Morgillo Dec 21 '12 at 15:44
  • Then it’s very simple. Run `git update-index --assume-unchanged ` – if you do that git will not commit that file, but you should get updates from the repo (you might want to test that). If you changed the file, do `git update-index --no-assume-unchanged ` before you commit. After the commit, run the first command again. If both of you do this, everything should be fine. – Chronial Dec 21 '12 at 23:37