1

I like having build numbers, just because it is cool. Please don't judge me :D.

However, I develop on two machines (one OS X and one Windows for portability checks). I have on both machines a script that automatically increases the build number every time I build the project. However, when doing changes on both machines without synchronising with git, this obviously gives a merge conflict, because the file holding the build number changed on both machines.

Is there a neat way to automatically merge these files? I would be cool if I could define a rule like:

If file buildnumber.txt has a merge conflict, run script auto-merge-build-number.sh and continue commit.

Where auto-merge-build-number.sh would be a simple script that parses the conflicted file and adds up the two numbers (found on the conflicting lines) and rewrites the file with that sum. I don't know if this is possible in git or not.

There is another way I can think of myself, but is less neat, imho: Keep track of a build counter file on every machine that is used only for that machine. If the project is build on that machine, the build counter file for that machine is increased. Afterwards, all files holding build numbers are added up together and the result is written to a file that is in the .gitignore. This way, there would be no merge conflicts by developing on multiple machines. Only merge conflicts by developing on multiple branches. I don't really like this approach because you need n+1 files to keep track of the total build number (when having n machines) and the script on every machine needs to be slightly different, to make it increase the right file.

Any thoughts on how this could be done?

closed as off-topic by user40980, unholysampler, gnat Dec 7 '15 at 4:50

  • This question does not appear to be about software engineering within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

3

Firstly, can you get away with using commits instead of builds?

git describe or git rev-list --count --first-parent HEAD can give you something like a revision number. Be careful if you have branches, it will do the wrong thing, but so will any build number.

Secondly, if you insist on using build numbers you want a custom merge driver.

See the documentation here: http://git-scm.com/docs/gitattributes#_defining_a_custom_merge_driver

Basically, you should be able to write a script to do whatever you want during merging.

  • +1: Nice. Thank you for the official documentation. This was what I was looking for. :) – Martijn Courteaux Dec 7 '15 at 0:31
  • Btw: I like build numbers because of the simple fancy thing that you can say: this project has had 15203 builds for example. :D – Martijn Courteaux Dec 7 '15 at 0:32
1

After searching some more, with different vocabulary, I found this post: http://nuclearsquid.com/writings/git-tricks-tips-workflows/ (section about .gitattributes)

Basically, this solution is the solution I was looking for and consists of two steps:

  • Create a merge strategy (for example called: buildnumbermerge) using a scripting language of choice and put it in .git/config (see link for details).
  • Specify which file should use which merge strategy. I.e.: buildnumber.txt should have merge strategy buildnumbermerge by specifying that in .gitattributes with a line like this:

    buildnumber.txt merge=buildnumbermerge
    

See also:

Not the answer you're looking for? Browse other questions tagged or ask your own question.