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

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

[Daniele Segato]

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

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

[Junio C Hamano]

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

> 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.

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 ;-)