2

In the web application I am working on we have a file called application.properties which looks like this:

#Grails Metadata file
#Thu Aug 27 10:21:00 BST 2015
app.buildDate=2015-08-27 1021
app.buildNumber=4404
app.buildProfile=development
app.grails.version=2.5.1
app.name=demo
app.servlet.version=3.0
app.version=5.0

The file needs to exist for the application to start

The values in this file will increment on each build, but it doesn't really matter to be exact. On every merge/branch switch this file causes merge conflicts. Is there a way to set a git setting that it should always just keep the target or source version (for this exact file)? It doesn't really matter most of the time.

Giannis
  • 5,286
  • 15
  • 58
  • 113
  • 5
    I'd recommend removing the file from your repository and generate it from the output of `git describe`. Especially a build date/number/profile should not be a part of the repository. – cmaster - reinstate monica Aug 27 '15 at 09:37
  • I was not aware of this command, but looking at docs not sure how it would be useful for this..? This file is generated and updated by the framework I use (Grails) – Giannis Aug 27 '15 at 09:46
  • 2
    If the file is already generated, it should not be part of the repo. Adding an autogenerated file to a repo only invites inconsistencies between the generated file and the data that it was generated from. Make sure that you generate your file at the appropriate step in the build process, remove it from the repo, and be done with it. – cmaster - reinstate monica Aug 27 '15 at 09:49
  • The file is generated/updated everytime the server runs. I am showing its values for buildnumber and version in the UI. It has to exist, I was just hoping there is a git setting(which I could not find) that will give instructions on the merge command as to what to do with this file. – Giannis Aug 27 '15 at 09:52
  • 1
    If the file is generated/updated everytime the server runs, why do you want to check it into your repository? Surely there are ways for you to ensure that the file exists when it is needed, without having a stale copy of it in the repo? Alternatively, if you absolutely want to be able to run your UI without generating the file first, surely it's possible to make the UI handle a missing file? In either case, the results would be more accurate than if you rely on the existence of a stale file in the repo. – cmaster - reinstate monica Aug 27 '15 at 10:22
  • @cmaster There are [use cases](http://blog.bfitz.us/?p=1811). Personally, I started using this when I was using Vagrant and provisioning a machine with a dynamically generated puppet manifest. The manifest had to exist before provisioning, otherwise vagrant would fail. So I created the file and used assume-unchanged on it. There is no way to ensure the file exists when it is needed, without making the workflow more complex (I couldn't just `vagrant provision` anymore). And sure, I'd like vagrant to be able to handle the missing file, but I have no control over that. – Paulo Almeida Aug 27 '15 at 10:48
  • @PauloAlmeida Yes, your use case seems valid. However, the use case of the OP does not seem valid to me. Of course, I may be mistaken. – cmaster - reinstate monica Aug 27 '15 at 10:59

2 Answers2

3

If you really want to keep it in the repository, you can do this:

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

Keeping the text above so the comments make sense, but --skip-worktree should be used for this.

Paulo Almeida
  • 7,803
  • 28
  • 36
  • The thing is this file is always updated by the framework I am using. So it will be changing. What I need is for git to just pick one of changes and apply it automatically, instead of asking me every time what to do.. – Giannis Aug 27 '15 at 09:45
  • With the command I gave you, git will keep the existing file in the repository and won't bother you in merges (no conflicts). I use this for generated files all the time. – Paulo Almeida Aug 27 '15 at 09:50
  • Right, then I can ignore it during dev, and only update it for deployments. Thanks will keep this in mind. – Giannis Aug 27 '15 at 09:53
3

In android, there is the file local.properties, which is generated by the android tools. You are advised to not store this in version control, as it is different from user to user.

That is an example where a 

git rm --cached filename

really helps, that is, removing it from version control. You might also tell git not to consider the file anymore by either saying

echo path/to/filename >> project/.git/info/exclude

or creating a file .gitignore with (or adding to it) the content

filename

As the @cmaster said:

I'd recommend removing the file from your repository

Also have a look at grails integrate-with --git (which seems to use .gitignore, as of this post).

serv-inc
  • 35,772
  • 9
  • 166
  • 188