Hi Roald, On Mon, Jul 20, 2009 at 6:54 AM, Roald de Vries<rdv@xxxxxxxxxxxxxxx> wrote: > I want to use git to synchronize my bashrc's (and other configuration files) > between computers. These have common stuff in them, and stuff that's > specific to a certain computer. The way I do it now is with a branch for > each computer, and one common branch. Is this a known use case, am I > misusing git, and is there a more elegant way to do this? I'm using git for the same purpose. I don't think you're going to find anyone who will get too dogmatic here and say there are any universally wrong ways to use git. If it works for you, you should probably just keep doing it. However, I could tell you what I'm doing. I use git to manage both my bash config files (.bashrc, .inputrc, .bash_profile) and my .emacs file (a tree .emacs.d). I manage these files for use on a Mac and a Windows Box running Cygwin. What I've done is I keep all common configuration items in one git repo with a single branch. If I'm working on something really large that will be broken for awhile, which is rare, then I'll branch out and go back to stable when I'm done working for the day. Once it's done, obviously, I merge it back in and delete the branch. Obviously, though, there is configuration that only belongs on one box or the other. For those, I have files that lie outside of my current repo that I call out to. I put them in the same relative locations on either box (obviously, Bash works the same on Cygwin and the Mac) and so my really local configuration lives on unbeknownst to my repo. If I can't locate that file outside of the repo (for instance, Emacs Easy Configuration file) then I use the .gitignore file to keep it out of my hair if there are items local to the box I'm on. That then begs the question of how to track the local files. You can always make a new git repo. That's easiest to do if the files are outside of the current repo because you can just make a new repo. If the file has to reside in the common repo, then it's a little more complicated. You may be able to use sub-repos combined with .gitignore files? I haven't had occasion to work this out yet. Hope that gives you some food for thought. Again, it's just how I happen to do things. Your approach sounds just as good to me. /me shrugs. -- In Christ, Timmy V. http://burningones.com/ http://five.sentenc.es/ - Spend less time on e-mail -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html