git refuses to switch to older branches

> now that gitweb.cgi is autogenerated, git refuses to switch to old
> branches unless force is applied:
> 
>       fatal: Untracked working tree file 'gitweb/gitweb.cgi' would
>       be overwritten by merge.
> 
> 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?

> Martin Waitz wrote:
>
>> now that gitweb.cgi is autogenerated, git refuses to switch to old
>> branches unless force is applied:
>> 
>>       fatal: Untracked working tree file 'gitweb/gitweb.cgi' would
>>       be overwritten by merge.
>> 
>> 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?
>
> I think it is "better to be annoying but safe" idea of git. You can always
> do "git checkout <branch> gitweb/gitweb.cgi" and "git checkout <branch>",
> and not use -f.

> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> Martin Waitz wrote:
>>
>>> now that gitweb.cgi is autogenerated, git refuses to switch to old
>>> branches unless force is applied:
>>> 
>>>       fatal: Untracked working tree file 'gitweb/gitweb.cgi' would
>>>       be overwritten by merge.
>>> 
>>> 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?
>>
>> I think it is "better to be annoying but safe" idea of git. You can always
>> do "git checkout <branch> gitweb/gitweb.cgi" and "git checkout <branch>",
>> and not use -f.
> 
> I think you are talking backwards.  Newer branch have .cgi
> generated and older branch has it tracked.  After you have built
> in a newer branch, checking out an older branch without -f
> option would play it safe not to clobber .cgi which is
> annoying.  So workaround you would want to suggest is TO USE -f.

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

> But I would suggest you to be _extremely_ careful if you want to
> 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.

> Dear diary, on Sun, Aug 20, 2006 at 12:39:20AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
> > But I would suggest you to be _extremely_ careful if you want to
> > 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.
> 
>   *.o and binary blobs of closed-source software.

> On Sun, Aug 20, 2006 at 12:44:57AM +0200, Petr Baudis wrote:
> > Dear diary, on Sun, Aug 20, 2006 at 12:39:20AM CEST, I got a letter
> > where Junio C Hamano <junkio@cox.net> said that...
> > > But I would suggest you to be _extremely_ careful if you want to
> > > 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.
> > 
> >   *.o and binary blobs of closed-source software.
> 
> but if you want to switch from one branch which has the .o file
> built from source to another branch which has the .o file tracked
> in binary form, wouldn't you want to remove the generated file
> in order to store the tracked one from the new branch?

> On Sun, 20 Aug 2006, Martin Waitz wrote:
> > On Sun, Aug 20, 2006 at 12:44:57AM +0200, Petr Baudis wrote:
> > > Dear diary, on Sun, Aug 20, 2006 at 12:39:20AM CEST, I got a letter
> > > where Junio C Hamano <junkio@cox.net> said that...
> > > > But I would suggest you to be _extremely_ careful if you want to
> > > > 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.
> > > 
> > >   *.o and binary blobs of closed-source software.
> > 
> > but if you want to switch from one branch which has the .o file
> > built from source to another branch which has the .o file tracked
> > in binary form, wouldn't you want to remove the generated file
> > in order to store the tracked one from the new branch?
> 
> Not necessarily. Sometimes you have files in your working directory, which 
> are not in your repository, you know?

> hoi :)
> 
> On Sun, Aug 20, 2006 at 02:48:34PM +0200, Johannes Schindelin wrote:
> > On Sun, 20 Aug 2006, Martin Waitz wrote:
> > > On Sun, Aug 20, 2006 at 12:44:57AM +0200, Petr Baudis wrote:
> > > > Dear diary, on Sun, Aug 20, 2006 at 12:39:20AM CEST, I got a letter
> > > > where Junio C Hamano <junkio@cox.net> said that...
> > > > > But I would suggest you to be _extremely_ careful if you want to
> > > > > 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.
> > > > 
> > > >   *.o and binary blobs of closed-source software.
> > > 
> > > but if you want to switch from one branch which has the .o file
> > > built from source to another branch which has the .o file tracked
> > > in binary form, wouldn't you want to remove the generated file
> > > in order to store the tracked one from the new branch?
> > 
> > Not necessarily. Sometimes you have files in your working directory, which 
> > are not in your repository, you know?
> 
> Sure. But we are only talking about files which are explicitly
> ignored in one branch and are tracked in another branch.
> 
> Perhaps it makes sense to check that the file is _not_ ignored in the
> other branch (in which it is tracked).
> Would such a check make everybody happy?

> 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

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

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

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

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

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