previously committed file untracked prevent checking out an old tag/branch

Hi,

I had this situation:

we used to have a properties file in our project that was used by ant to build it. That file was tracked since the beginning of the project (several months ago).

let's call it: build.properties

(the project is on SVN and I'm the only one to use git)

Since everyone in the project has different directories paths I decided to untrack the file create a new template file and track it instead:

so I did something like this:

cp build.properties build.properties.template vim build.properties.template echo build.properties >> .git/info/exclude git rm --cached build.properties git add build.properties.template git commit -m "finally we don't overwrite it each other anymore"

Now I had to switch back to a tag that still have that file (build.properties) tracked to fix some issue there but when I try I get:

error: Untracked working tree file 'build.properties' would be overwritten by merge.

How would you handle a situation like this?

I only can think of doing a backup of my build.properties, delete it and check out the tag or I just delete it and rebuild it from the template later.

I did it but that made me think on it.

Actually what I really wanted here was the possibility to "locally track" that file...

something like git local <file>

that will have that file indexed by git so I can switch to branch that have that file without loosing it when I go back. furthermore that would allow me to keep versions of my local file even if I don't want to commit it. I could see if I accidentally modified it.

This could be useful, in my opinion.

Is there on git a feature to do something like that? Do you think it could be useful or do you see any possible problem about that?

Regards, Daniele

Daniele Segato <daniele.bilug@gmail.com> writes:

That is the right approach, but you could automate it further.

The project I help at work has a similar set-up. The Makefile defines a plain vanilla set of configuration via the Make variables, and they can be overriden by including ./config.mk. The master branch does not have the file tracked, but ./config.mk-sample file is tracked and the developers can use it as a template.

The developers can have an untracked (from the project's point of view) subdirectory, local/. with local/myconfig.mk file. "local" is in fact a full fledged git repository with local/.git and changes to myconfig.mk can be tracked there. It is not (and should not be) a subproject.

Because what appear in the sample config.mk-sample are a bunch of Make variable definitions, and in Make, later definition trumps the earlier ones, So the developers can do:

	$ cat config.mk-sample local/myconfig.mk >config.mk
        $ make

The first step can be in the Makefile; the above command line is for illustration.

For branches that are used for specific customer release, we track their config.mk file. That means the developer would lose config.mk file if he does this:

	$ git checkout master
	$ cat config.mk-sample local/myconfig.mk >config.mk
        $ make
	... do the usual work of developing and testing ...
        $ git checkout customer ;# may fail due to config.mk
        $ rm -f config.mk	;# so get rid of it
        $ git checkout customer ;# now it is ok
        $ make			;# for real release
        ... or perhaps to diagnose the issue at customer site  ...
        $ edit config.mk	;# minimally adjust for testing
        $ make
        $ test
	... done, and go back to the regular programming ...
        $ git checkout config.mk ;# get rid of local changes
        $ git checkout master

But because the real configuration is tracked in local/.git, there is no information lossage.

The generic config.mk _could_ be written to include local/myconfig.mk if exists, in order to help debugging or testing the customer branch (then there is no need for "edit config.mk for testing and then revert" steps), but we chose not to do so, as it risks the release/build engineer to forget that he has funny customization in his local/myconfig.mk file and screwing up the release by inadvertently including the customization.

HTH ;-)