Re: git refuses to switch to older branches
- From
Alex Riesen <fork0@t-online.de>
- Date
- Sep 8, 2006, 22:00 UTC
- Message-ID
- <20060908220053.GA6011@steel.home>
- In-Reply-To
- <20060820121935.GF30022@admingilde.org>
Sorry for the answer long overdue, I was on vacation, and quite off of the internet.
Martin Waitz, Sun, Aug 20, 2006 14:19:35 +0200:
Show 21 quoted lines
> On Sun, Aug 20, 2006 at 09:26:12AM +0200, Alex Riesen wrote: > > Junio C Hamano, Sun, Aug 20, 2006 00:39:20 +0200: > > > Martin Waitz <tali@admingilde.org> writes: > > > > > > > This safety measure is quite useful normally, but for files that are > > > > explicitly marked as to-be-ignored it should not be neccessary. > > > > > > > > But all the code that handles .gitignore is only used by ls-files now. > > > > Does it make sense to add exclude handling to unpack-trees.c, too? > > > > > > In principle, I am not opposed to the idea of making read-tree > > > take the ignore information into consideration. > > > > > > But I would suggest you to be _extremely_ careful if you want to > > > > It should be optional. And off by default, people already have got > > scripts depending on this behaviour (well, I have). > > but having this sort of behaviour optional is bad, I think. > Some people will depend on one semantic and others on the other. > And then get bite if they want to share their scripts.
So at least give the people who got there first a chance to have their scripts working. Why break them?
> We have to find _one_ semantic that always works.
Well, the current semantics always work.
Show 13 quoted lines
> > > try this. I do not have an example offhand, but I would not be > > > surprised at all if there is a valid use case where it is useful > > > to have a pattern that matches a tracked file in .gitignore > > > file. > > > > Ignored directory and but some files/subdirectories in it are tracked, > > because this is temporary or externally changed data (I have both > > examples). > > but do you have non-tracked files in the ignored directory that you > really care about, i.e. which must not be overridden by a tracked file > with the same name? >
I don't, but I can easily imagine someone has: a file contained some build-local configuration, which developer later decided to start tracking. Like config.mak in git.