Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm new to git.

I'm using a development platform called automation studio. This development tool creates all sorts of files and directories which it needs to maintain runtime and IO information for the target processor. These informations are specific for each project. Therefore these file should not be under version control because they are provided and maintainded by the platform. Otherwise one cannot run the automation studio without these files.

I put the names of these files and directories in an .gitignore file. Then I cloned myrepository to a bare repository on a server. Then I cloned back to mynewrepository on my local machine. Unfortunatedly in mynewrepository all files and directories listed in .gitignore were missing. Therefore the automation studio platform failed to work.

How can I exclude these files and the content of these directories from versioning but keep the them all in the repository in order to clone back a fully working project for automation studio?

share|improve this question
3  
Uh... you want to exclude files from the repository but still keep them in the repository? That sounds contradictory. You don't want the cake but still want it? Why don't you want the project files versioned? –  Spoike Mar 9 '13 at 8:57
    
sounds more like you have some common components which should be seperated from your projects into a common library. project files/build scripts almost certainly should be checked in for each project. –  jk. Mar 9 '13 at 9:26

2 Answers 2

Sometimes there comes situations where you want to add configuration to version control but they change depending on where you've cloned the project. How to "semi-ignore" these files depends totally on how you want it to work. So here are some strategies for it:

Strategy No. 1: Commit ALL THE THINGS

enter image description here

You should try to commit everything and see later on what you don't need. Sometimes this is the best solution. It is more common for us to assume that we don't need them in version control until we realize that we do.

You can also follow it up with temporarily assuming files as unchanged in git. The command you can use to do this with is git update-index:

git update-index --assume-unchanged [file ...]

If you have trouble doing this with directories, read this SO question on assuming directories with untracked files.

Strategy No. 2: If a tool sets up the project, use it to generate the configuration and then clone on top of that

You can do what you've done now, ignore the configuration in git and when you want to clone the project you do that on top of a new project that is created by the tool. Or write your own tool (a batch script) to set up the project for you.

Strategy No. 3: Check in "default" configuration shared between projects

You could try to figure out which configuration is the bare minimum that you need and have that committed to the repository.

If you want configuration defaults, you could copy (or zip) all the configuration files to a seperate directory and then have that committed. When you clone, you can then unzip all those files to the correct spot to get things going.

You can batch this installation process to make it easier for you to get going. So that you only need to run it once when you clone the project.

Bonus Strategy: Check in a "readme" text file that details a process of how to get started

Checking in a text file that details how you go about to set up the project is a useful thing to do. You may need this later on to remind yourself how you've set up the project.

share|improve this answer
    
Could also make a separate branch with those files in them? –  kyrias Mar 31 '13 at 15:50
    
@Demizey: I wouldn't do that as there are several problems with handling configuration variants in version control as a separate branch. Shortly explained: since you need to manage each and every variant you need to update them every time you make a change (or need to make a release) that alone is a maintenance nightmare and a trap enterprise projects fall into. The management of variants is easier done through the application (if it auto-generates the settings) or creating a script file that generates the settings for you, or anything similar. –  Spoike Mar 31 '13 at 18:29

This cannot possibly work. Git cannot clone any files that it doesn't even know exist. That doesn't even have anything to do with Git, that's just basic common sense.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.