{"thread":{"id":"20902","subject":"previously committed file untracked prevent checking out an old tag/branch","startedAt":"2009-09-11T11:26:35Z","lastAt":"2009-09-12T00:06:37Z","messageCount":2,"participants":["Daniele Segato","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"122884","messageId":"9accb4400909110426v2a42086ema318167e94b2cbc1@mail.gmail.com","threadId":"20902","inReplyTo":null,"subject":"previously committed file untracked prevent checking out an old tag/branch","fromName":"Daniele Segato","fromEmail":"daniele.bilug@gmail.com","sentAt":"2009-09-11T11:26:35Z","receivedAt":"2009-09-11T11:26:35Z","isPatch":false,"sender":{"key":"daniele.bilug@gmail.com","avatar":null},"body":"Hi,\n\nI had this situation:\n\nwe used to have a properties file in our project that was used by ant\nto build it.\nThat file was tracked since the beginning of the project (several months ago).\n\nlet's call it:\nbuild.properties\n\n(the project is on SVN and I'm the only one to use git)\n\nSince everyone in the project has different directories paths I\ndecided to untrack the file\ncreate a new template file and track it instead:\n\nso I did something like this:\n\ncp build.properties build.properties.template\nvim build.properties.template\necho build.properties >> .git/info/exclude\ngit rm --cached build.properties\ngit add build.properties.template\ngit commit -m \"finally we don't overwrite it each other anymore\"\n\nNow I had to switch back to a tag that still have that file\n(build.properties) tracked to fix some\nissue there but when I try I get:\n\nerror: Untracked working tree file 'build.properties' would be\noverwritten by merge.\n\nHow would you handle a situation like this?\n\nI only can think of doing a backup of my build.properties, delete it\nand check out the tag or I just delete it and rebuild\nit from the template later.\n\nI did it but that made me think on it.\n\nActually what I really wanted here was the possibility to \"locally\ntrack\" that file...\n\nsomething like\ngit local <file>\n\nthat will have that file indexed by git so I can switch to branch that\nhave that file without loosing it when I go back.\nfurthermore that would allow me to keep versions of my local file even\nif I don't want to commit it.\nI could see if I accidentally modified it.\n\nThis could be useful, in my opinion.\n\nIs there on git a feature to do something like that?\nDo you think it could be useful or do you see any possible problem about that?\n\nRegards,\nDaniele\n"},{"id":"122926","messageId":"7vvdjpowky.fsf@alter.siamese.dyndns.org","threadId":"20902","inReplyTo":"9accb4400909110426v2a42086ema318167e94b2cbc1@mail.gmail.com","subject":"Re: previously committed file untracked prevent checking out an old tag/branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-12T00:06:37Z","receivedAt":"2009-09-12T00:06:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniele Segato <daniele.bilug@gmail.com> writes:\n\n> I only can think of doing a backup of my build.properties, delete it\n> and check out the tag or I just delete it and rebuild\n> it from the template later.\n\nThat is the right approach, but you could automate it further.\n\nThe project I help at work has a similar set-up.  The Makefile defines a\nplain vanilla set of configuration via the Make variables, and they can be\noverriden by including ./config.mk.  The master branch does not have the\nfile tracked, but ./config.mk-sample file is tracked and the developers\ncan use it as a template.\n\nThe developers can have an untracked (from the project's point of view)\nsubdirectory, local/. with local/myconfig.mk file.  \"local\" is in fact a\nfull fledged git repository with local/.git and changes to myconfig.mk can\nbe tracked there.  It is not (and should not be) a subproject.\n\nBecause what appear in the sample config.mk-sample are a bunch of Make\nvariable definitions, and in Make, later definition trumps the earlier\nones,  So the developers can do:\n\n\t$ cat config.mk-sample local/myconfig.mk >config.mk\n        $ make\n\nThe first step can be in the Makefile; the above command line is for\nillustration.\n\nFor branches that are used for specific customer release, we track their\nconfig.mk file.  That means the developer would lose config.mk file if he\ndoes this:\n\n\t$ git checkout master\n\t$ cat config.mk-sample local/myconfig.mk >config.mk\n        $ make\n\t... do the usual work of developing and testing ...\n        $ git checkout customer ;# may fail due to config.mk\n        $ rm -f config.mk\t;# so get rid of it\n        $ git checkout customer ;# now it is ok\n        $ make\t\t\t;# for real release\n        ... or perhaps to diagnose the issue at customer site  ...\n        $ edit config.mk\t;# minimally adjust for testing\n        $ make\n        $ test\n\t... done, and go back to the regular programming ...\n        $ git checkout config.mk ;# get rid of local changes\n        $ git checkout master\n\nBut because the real configuration is tracked in local/.git, there is no\ninformation lossage.\n\nThe generic config.mk _could_ be written to include local/myconfig.mk if\nexists, in order to help debugging or testing the customer branch (then\nthere is no need for \"edit config.mk for testing and then revert\" steps),\nbut we chose not to do so, as it risks the release/build engineer to\nforget that he has funny customization in his local/myconfig.mk file and\nscrewing up the release by inadvertently including the customization.\n\nHTH ;-)\n"}]}