1

When I develop code, I typically have a bunch of "personal" files that I don't want to share with other developers because they are peculiar to my own idiosyncratic workflow. These files include personal Makefiles, little test scripts, test data files, etc. This hasn't been a terrible problem: I just itemize these files in .gitignore and no else needs to be bothered by my squirrelly ways.

All is not utterly copacetic, however. If I clone this repository, for instance, my personal test files do not come along for the ride, and also these files are not versioned. I.e., as the code changes, my test files and scripts and Makefiles need to change along with the code. If I revert to an earlier version of the code, my scripts and test files are now broken. Or if I'm working from home, and I pull from my Git clone on my work computer, these personal files don't get pulled to my home computer.

So, what would be really keen is if Git had a notion of tracked and shared files as being different from tracked and private files. When I push to a shared repository, the private files would not be pushed, even though Git is tracking them and versioning them for me. And when I clone a repository, I would have the choice of getting only the shared files, or both the shared and private files.

I willing to hazard a guess that I'm just SOL as far as this feature goes, but ya' never know. Git seems to do just about everything, so maybe it has a way of doing this too, and I've just been left out of the loop.

One possible work-around is to make a subdirectory for this stuff (e.g., "dougs-personal-crap") and tell my coworkers not to mess with it. But I don't really want to be airing out my dirty laundry so, especially if there's a better way.

Douglas
  • 2,555
  • 3
  • 24
  • 30
  • 1
    You could take the subdirectory approach a step further and make it a separate git repository. Inconvenient but it would get the job done. – Casey Robinson Jan 13 '12 at 18:50
  • http://stackoverflow.com/questions/8721984/git-ignore-files-for-public-repository-but-not-for-private might also help. – Casey Robinson Jan 13 '12 at 18:52

2 Answers2

2

I can think only one pretty good way to do this.

  1. Divide all staff to private and public
  2. Move public stuff to XXX repository
  3. Move private stuff to YYY repository
  4. Create a big super repository ZZZ
  5. Add XXX and YYY to ZZZ repository as submodules

As a result you have repository which contains some public stuff and your private data, scripts etc. You can easily clone your ZZZ repository. Also you can easily share XXX repository. Enjoy!

Oleksandr Pryimak
  • 1,561
  • 9
  • 11
  • Hmmm, I just went and skimmed the Pro Git chapter on submodules. It looks promising, though submodules seem like a big hammer for this job, and there are all these little gotcha's that you apparently have to look out for when using submodules. I'll have to give it a try. Thanks! – Douglas Jan 13 '12 at 19:33
  • @Douglas I also think that using submodules almost always overkill (beyond several use cases). Also it is much more complicated to use. But I like them. Good luck! – Oleksandr Pryimak Jan 13 '12 at 21:19
1

Another approach would be to use mine.

It let's you keep personal stuff in a git tracked directory, away from git, and backup-able.

user3276552
  • 1,074
  • 12
  • 15