Re: git refuses to switch to older branches

[fork0@t-online.de (Alex Riesen)]

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

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