0

I have a project that looks like this: 

src
build
  | - build.xml
  | - build.properties

The build.properties file will be different on every developers machine.

Generally our teams method is to never commit the build.properties file unless new properties have been added to it.

This solution is not ideal. It means that each dev's properties file isn't versioned unless they do something tricky.

Is there a standard way to handle this kind of thing in Git?

The same issue applies to:

  • Properties files
  • Project settings (specificity in eclipse)
  • Other changes that should be kept and versioned but never pushed to other dev's machines

Thanks!

Edit: It would also be sweet if the files didn't show up here:

# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   .settings/org.eclipse.wst.common.component
#   modified:   .settings/org.eclipse.wst.common.project.facet.core.xml
#   ...many more
sixtyfootersdude
  • 25,859
  • 43
  • 145
  • 213
  • SVN the files locally. Or create a folder on the git and have every dev Name their file ( This would be for a backup, I'm assuming). It's a bit clunky though. Realistically, How can GIT know to keep multiple version of this file for each user? – SH- Jun 10 '13 at 21:44
  • @SH- I imagine that this is an issue faced by everyone using git so there must be some standard solution. – sixtyfootersdude Jun 10 '13 at 21:48
  • Yah, I would like to know, it is useful. It just seems to run quite opposite the core makeup of GIT. – SH- Jun 10 '13 at 21:51
  • Possibly related: http://stackoverflow.com/questions/8721984/git-ignore-files-for-public-repository-but-not-for-private – Gary Fixler Jun 10 '13 at 22:30
  • From a comment at that link, this seems directly related, as well as eye-strainingly red: http://dave.is/junk/ - though it seems like a wrapper around the symlink thing we discussed elsewhere. – Gary Fixler Jun 10 '13 at 22:31

2 Answers2

0

If you're on Linux the devs can store those files out in a separate, local repo, then symlink them into the right place in the development repo, and add them to their .gitignore files there. This would put the onus on the devs to go to their settings repo to commit changes, though, as the dev repo won't remind them that settings files have changed.

If these can be bundled up into one folder, they could be made a submodule locally. Then at least there would be some notification that the settings submodule had "changes" in it. The nice thing about this is that you can have build and other settings stay in sync with the code. I don't know how relevant that is, but you might make changes in code that call for changes in e.g. compile settings, and this would keep those tied together through history on a per-dev basis.

Gary Fixler
  • 5,632
  • 2
  • 23
  • 39
  • Yeah, that is what I do at home for my dot files (.bashrc, .vimrc, etc) but at work we are on windows so the symlink solution doesn't work. – sixtyfootersdude Jun 10 '13 at 21:46
  • Windows does have symlinks these days, though they're a bit clunky: http://en.wikipedia.org/wiki/NTFS_symbolic_link – Gary Fixler Jun 10 '13 at 21:48
0

What I ended up doing was committing all of the files on the branch devEnv-Jake. Then when I want to pull them in I run jake-mergeDevEnv-git which is aliased to this: 

alias jake-mergeDevEnv-git='git merge --no-ff --no-commit devEnv-Jake ; git reset'

Downside is you have to be careful not to commit those files to the branch you are working on.

sixtyfootersdude
  • 25,859
  • 43
  • 145
  • 213