git refuses to switch to older branches

git refuses to switch to older branches

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

hoi :)

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: git refuses to switch to older branches

[Jakub Narebski]

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.

Or add gitweb.cgi to .gitignore in the old branch.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git refuses to switch to older branches

[Junio C Hamano]

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.

Re: git refuses to switch to older branches

[Junio C Hamano]

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.

> Or add gitweb.cgi to .gitignore in the old branch.

And this "adding something to old one" is nonsense ;-).

Re: git refuses to switch to older branches

[Petr Baudis]

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: git refuses to switch to older branches

[Jakub Narebski]

Junio C Hamano wrote:

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

If I remember correctly that is what I did when "master" (and I had switch
to master to do "git pull origin") didn't contain gitweb.cgi -> gitweb.perl
rename. My proposed solution first overwrites generated gitweb.cgi by
tracked file (i'm not sure if this is feature or bug that git-checkout
with file specified (path limit specified?) doesn't need -f, and then
you can do git-checkout full branch without -f.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git refuses to switch to older branches

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> ... I'm not sure if this is feature or bug that git-checkout
> with file specified (path limit specified?) doesn't need -f

This is definitely a feature we deliberately added long after
git-checkout was initially written, in reponse to specific
requests from users.  Back then the only way to revert to index
or HEAD was to "checkout-index -f -q -u -a" or "reset --hard"
and it was cumbersome to revert only a single path.

I have been wondering if we wanted to be able to say:

	git checkout HEAD gitweb/

to revert everything under named hierarchy, but we haven't heard
user requests for this.  This is way more dangerous than my
liking so personally I am happy that we do not have it.

Re: git refuses to switch to older branches

[Alex Riesen]

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

Re: git refuses to switch to older branches

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]

hoi :)

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.
We have to find _one_ semantic that always works.

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

-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: git refuses to switch to older branches

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

hoi :)

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?

-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: git refuses to switch to older branches

[Johannes Schindelin]

Hi,

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?

Ciao,
Dscho

Re: git refuses to switch to older branches

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

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?

Is there an easy way to check if some file is marked as ignored in
an other branch?


-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: git refuses to switch to older branches

[Johannes Schindelin]

Hi,

On Sun, 20 Aug 2006, Martin Waitz wrote:

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

Actually, I am very happy with the strict checking, and that I can 
override it with "-f".

Ciao,
Dscho

Re: git refuses to switch to older branches

[Josef Weidendorfer]

On Sunday 20 August 2006 14:48, you wrote:
> Not necessarily. Sometimes you have files in your working directory, which 
> are not in your repository, you know?

Yet, I think it is quite inconvenient the way it is now. The same happens if
you track a generated file by accident, and remove it later from tracking.

The real problem is that there are two reasons to put a file into .gitignore:
You do not want to have it tracked and polluting git-status because
(1) it is temporary and generated
(2) it is private and not supposed to be in the repository

To distinguish these cases, we could introduce a per-repository configuration
file .git/nevertouch . Comments?

Josef

Re: git refuses to switch to older branches

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