3

I've a committed file "build.properties", this file has to be on our project repository as it contains important build information.

Sometime some developer performing some local testing, change the content of this file, and then they commit the changes by mistake (by simply staging all the changes they made, build.properties included).

Now I would like, somehow, to ignore all the local changes made to this file in order to avoid this situation that keep braking the build, so for example when the developer will run a *git add ** or a git commit -a, that file won't be included in the staged file.

I did already some research, but till now I cannot find any solution compatible with what i'm looking for, considering that the operation needs to be applied remotely, for example I can use the .git/info/exclude folder, but then every time a new developer will clone the repository, he will have to set the .git/info/exclude again, and I would like to avoid this.

Moreover, .gitignore works just with un-tracked file, if I add a tracked file to .gitignore, it won't be ignore at all. I found some persons suggesting to use .gitignore in combination with git rm --cached then re-add the files, but once the file were re-added to the tree, the changes were keeping being tracked, also reading from offical GIT doc, .gitignore does not look to be suitable for my needs.

Any solution in mind? Thanks!

UPDATE

I'm a big fan of SVN, and more I know GIT, more I appreciate SubVersion.

So I guess, the answer to my question is GIT does not provide any way to achieve something like this...

Agree that would not be the best of the practices and that there are other ways to achieve what i'm asking without managing it with the famous source control tool GIT, but my intention is still something quite common that we can face in many different contexts.

I mean GIT provide ways to get around most of the standard practices and principles, for example I can't change a remote history for principle, but GIT gave me the --force to achieve this, so I wonder why it does not provide an easy way to get around my issue too.

ivoruJavaBoy
  • 1,307
  • 2
  • 19
  • 39

2 Answers2

2

I understand what your trying to do and the reasons behind it are valid ones. But the thing is, it contradicts the distributed and parallel nature of Git. Git is designed to be a:

Version-control system for tracking changes in computer files and coordinating work on those files among multiple people

If your file is being taken care by Git, it assumes the file may be changed and needs to be tracked (otherwise why bother with a version-control system). As you pointed out, it is possible to do it locally because it is one isolated decision to tell Git that in your own machine that you do not want to commit changes to that file. Trying to do it globally is basically like trying to use Git as a simple file storage system.

Therefore, keeping in mind that Git is not designed to do what you want, you might want to consider a few options:

  1. All developers in your team must tell Git locally that they don't want to commit modifications to that file: It is a workaround. And the cost of this is to have to do it every time you clone the repo. If you choose this, you might want to consider using git update-index --skip-worktree <file> (you can read more about why use instead of other options here);
  2. Check-out Git extensions and find out if one of them accommodate your needs: I've never use it, but I know Git LFS supports file locking. It was not build for what you're trying to do, but it may be an option;
  3. Change your problem solving approach: If you're using Git and you have a need that it is not accommodated by it, you can either fight Git or use it as it is and find other way to do what you want. After all, Git is very usefull for tracking things and you might as well want to change and commit your file in the future. How about thinking a way to separating your 'default' properties file(s) (the one(s) commited in the repo) from your development properties file(s) (that can change according to each developer need)? I am not familiar to your development environment, but I'm confident you can find a way to use your default file if no other one was specified and to use a specific one if it was specified.
Aurora Wang
  • 1,822
  • 14
  • 22
  • 1
    Hi Aurora, I like your answer and I was expecting it, yeah what I want to do may contradicts GIT nature and in general SCM nature, I'm totally agree, and we do have other solutions, for example pointing an env variable from the build.prop instead of hard coding the values, definitely a cleaner solution, but we wanted to check if GIT supports something like this somehow, thanks for you advices, i'll check them out. – ivoruJavaBoy Dec 07 '18 at 11:52
0

The better way would be to have multiple build.properties for different environments.

Example: buildDev.properties for development environment, similarly buildTest.properties and buildProd.properties for test and prod environment.

Note: git rm --cached is used when you have pushed a file to remove which you shouldn't have and now also want to untrack it. You can add the file name in .gitignore in this case and then use git rm --cached to delete it from staging area and then commit. Now this commit removes the file which can be pushed to master without removing the file locally.

Rishabh Agarwal
  • 1,988
  • 1
  • 16
  • 33
  • 1
    No, this is incorrect. `.gitignore` doesn't help with files already tracked by git. – Lasse V. Karlsen Dec 07 '18 at 10:31
  • Thanks for you answer Rishabh, unfortunately, as said in the question the .gitIgnore does not help with files already tracked by GIT, If i add the file to the .gitignore and than run a git status or a git add * the file is shown and is staged, are you sure about what you said? maybe there is a step in the middle i'm missing, did you ever test this solution? – ivoruJavaBoy Dec 07 '18 at 11:03
  • `git rm --cached` preserves the file locally but the file will be removed in any remote repository that pulls the change. Ouch! :-( – phd Dec 07 '18 at 13:55
  • @LasseVågsætherKarlsen , thanks for the info. It doesn't work. Editing the answer. – Rishabh Agarwal Dec 08 '18 at 12:16