[bug] git-add won't add foo/.git/bar

[bug] git-add won't add foo/.git/bar

[Michael Gebetsroither]

hi,

% git-add -f foo/.git/bar
fatal: unable to add foo/.git/bar to index

How do i add such a file to a git repository?

thx && cu,
michael
-- 
It's already too late!

Re: [bug] git-add won't add foo/.git/bar

[Julian Phillips]

On Tue, 25 Mar 2008, Michael Gebetsroither wrote:

> hi,
>
> % git-add -f foo/.git/bar
> fatal: unable to add foo/.git/bar to index

Well, git won't allow .git as a element anywhere in the path, when we 
should only care about the _first_ one - and also, if you use 
--git-dir=banana then we still check for '.git' ... oops.

patch in the works ... ;)

>
> How do i add such a file to a git repository?

wait? :P

Sorry, can't see any easy way to work around this atm.

>
> thx && cu,
> michael
>

-- 
Julian

  ---
"May the forces of evil become confused on the way to your house."
-- George Carlin

Re: [bug] git-add won't add foo/.git/bar

[Junio C Hamano]

Julian Phillips <julian@quantumfyre.co.uk> writes:

> On Tue, 25 Mar 2008, Michael Gebetsroither wrote:
>
>> hi,
>>
>> % git-add -f foo/.git/bar
>> fatal: unable to add foo/.git/bar to index
>
> Well, git won't allow .git as a element anywhere in the path, when we
> should only care about the _first_ one - and also, if you use
> --git-dir=banana then we still check for '.git' ... oops.

That's not how git-dir is supposed to used, so there is no oops.

Also it is false that we should only care about the first one.  Think
submodules.

Re: [bug] git-add won't add foo/.git/bar

[Julian Phillips]

On Mon, 24 Mar 2008, Junio C Hamano wrote:

> Julian Phillips <julian@quantumfyre.co.uk> writes:
>
>> On Tue, 25 Mar 2008, Michael Gebetsroither wrote:
>>
>>> hi,
>>>
>>> % git-add -f foo/.git/bar
>>> fatal: unable to add foo/.git/bar to index
>>
>> Well, git won't allow .git as a element anywhere in the path, when we
>> should only care about the _first_ one - and also, if you use
>> --git-dir=banana then we still check for '.git' ... oops.
>
> That's not how git-dir is supposed to used, so there is no oops.

So I can't _ever_ have a directory/file called '.git'?  But I _can_ add 
files inside my repository provided that the repository is not called 
.git?  How is that not an oops, or extremely confusing at the least?

i.e.:

'git add .git/fred' fails
'git --git-dir=.git_repos --work-tree=. add .git/fred' fails
'git --git-dir=.git_repos --work-tree=. add .git_repos/fred' works

> Also it is false that we should only care about the first one.  Think
> submodules.

Ok, true.  I've never used submodules, can you add things inside 
submodules from the parent?  If so, where do they get added - presumably 
to the submodule?

> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
Julian

  ---
Ya'll hear about the geometer who went to the beach to catch some
rays and became a tangent ?

Re: [bug] git-add won't add foo/.git/bar

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>> Well, git won't allow .git as a element anywhere in the path, when we
>> should only care about the _first_ one - and also, if you use
>> --git-dir=banana then we still check for '.git' ... oops.
>
> That's not how git-dir is supposed to used, so there is no oops.

The only purpose of git-dir is to have $GIT_DIR elsewhere _outside_ the
work tree.

That is, not "git --git-dir=banana", but "git --git-dir=$(pwd)/../banana"
or more typically "git --git-dir=/home/gits/banana.git/" when you are at
the toplevel of your work tree that is unrelated to the named location.

> Also it is false that we should only care about the first one.  Think
> submodules.

Actually, not just "submodules", but even with more traditional "overlayed
checkout" with working in a subdirectory, you would have problems.

You can have another repository in your work tree, and the way we tell
which path belongs to which repository is by finding .git directory in the
hierarchy.  In my work trees of git.git, I have a clone of the repository
itself in Meta/ and have checkout of 'todo' branch, like this:

	/git.git/.git
        	/COPYING
                /Documentation
                /Makefile
                /Meta/.git
                /Meta/Doit
                /Meta/MaintNotes
                /Meta/Make
                ...

In such a layout, you can

	$ cd Meta
        $ edit MaintNotes
        $ git commit

and commit the result to the /git.git/Meta/.git/ repository, while you can

	$ cd Documentation
        $ edit git.txt
        $ git commit

and the result is committed to the main /git.git/.git/ repository.

What this means is that you cannot have .git/ directory anywhere in your
work tree unless the directory that house such a .git directory as its
direct subdirectory (e.g. /git.git/Meta in the above illustration) unless
that hierarchy does not belong to the main repository (e.g. /git.git/).

Having, say Documentation/.git, in the above example is wrong because you
want the file Documentation/git.txt to be part of the main project.

And trying to add Documentation/.git/garbage is doubly wrong.  For one
thing, that path is a place to hold metainformation of the
/git.git/Documentation/.git repository (i.e. not something you can "git
add" to the /git.git/Documentation/.git repository), and because it is
part of /git.git/Documentation/.git repository, it should not even go to
the main project (i.e. not something you can "git add" to the main
/git.git/.git repository either).

A few weeks ago somebody wanted to rename .git and I thought I responded
well enough.  You certainly did not ask CVS or SVN folks to rename the
control directories they sprinkle in your work trees to .cvs or .svn, did
you?  Leave .git alone so that people don't get confused.

Re: [bug] git-add won't add foo/.git/bar

[Julian Phillips]

On Mon, 24 Mar 2008, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
>
>>> Well, git won't allow .git as a element anywhere in the path, when we
>>> should only care about the _first_ one - and also, if you use
>>> --git-dir=banana then we still check for '.git' ... oops.
>>
>> That's not how git-dir is supposed to used, so there is no oops.
>
> The only purpose of git-dir is to have $GIT_DIR elsewhere _outside_ the
> work tree.

That's fair enough.  It's not enforced, or discourgaed in the 
documentation though.  Would a patch to mention that using 
--git-dir/GIT_DIR to change the name _inside_ the work tree is not 
supported be accepted?

> A few weeks ago somebody wanted to rename .git and I thought I responded
> well enough.  You certainly did not ask CVS or SVN folks to rename the
> control directories they sprinkle in your work trees to .cvs or .svn, did
> you?

Well, no - but then I hold git to a higher standard. ;)

> Leave .git alone so that people don't get confused.

Agreed, it is a) a lot simpler to explain, b) less likely to break things. 
Sorry for wasting your time :$, an interesting poke around the code 
though. :)

Something I noticed that seemed a bit odd when playing with this, should I 
expect git to stop me from trying to add files inside subprojects to the 
main project?  It seems to just discard the submodule and turn it into a 
normal directory when I do.  Is that intended behaviour?

-- 
Julian

  ---
Excess on occasion is exhilarating.  It prevents moderation from
acquiring the deadening effect of a habit.
 		-- W. Somerset Maugham

[PATCH] Documentation/git.txt: Mention unsupported use of --git-dir/GIT_DIR

[Julian Phillips]

We don't support using --git-dir/GIT_DIR to change the name of the
.git directory, so make this clear in the documentation.

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
On Tue, 25 Mar 2008, Julian Phillips wrote:

> On Mon, 24 Mar 2008, Junio C Hamano wrote:
>
>>  Junio C Hamano <gitster@pobox.com> writes:
>> 
>> > >  Well, git won't allow .git as a element anywhere in the path, when
we
>> > >  should only care about the _first_ one - and also, if you use
>> > >  --git-dir=banana then we still check for '.git' ... oops.
>> > 
>> >  That's not how git-dir is supposed to used, so there is no oops.
>> 
>>  The only purpose of git-dir is to have $GIT_DIR elsewhere _outside_ the
>>  work tree.
>
> That's fair enough.  It's not enforced, or discourgaed in the
> documentation though.  Would a patch to mention that using --git-dir/GIT_DIR
> to change the name _inside_ the work tree is not supported be accepted?

i.e. this ...

 Documentation/git.txt |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/git.txt b/Documentation/git.txt
index 3ed24d4..28cce7f 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -134,7 +134,8 @@ help ...'.
 
 --git-dir=<path>::
 	Set the path to the repository. This can also be controlled by
-	setting the GIT_DIR environment variable.
+	setting the GIT_DIR environment variable. Setting this to use a name
+	other than `.git` _inside_ the working tree is not supported.
 
 --work-tree=<path>::
 	Set the path to the working tree.  The value will not be
@@ -391,7 +392,8 @@ git so take care if using Cogito etc.
 'GIT_DIR'::
 	If the 'GIT_DIR' environment variable is set then it
 	specifies a path to use instead of the default `.git`
-	for the base of the repository.
+	for the base of the repository. Setting this to use a name
+	other than `.git` _inside_ the working tree is not supported.
 
 'GIT_WORK_TREE'::
 	Set the path to the working tree.  The value will not be
-- 
1.5.4.4

Re: [bug] git-add won't add foo/.git/bar

[Michael Gebetsroither]

* Junio C Hamano <gitster@pobox.com> wrote:
> Julian Phillips <julian@quantumfyre.co.uk> writes:
>> On Tue, 25 Mar 2008, Michael Gebetsroither wrote:

>>> % git-add -f foo/.git/bar
>>> fatal: unable to add foo/.git/bar to index

> Also it is false that we should only care about the first one.  Think
> submodules.

Would it be possible to allow it with git-add -f or does that break to
many cases?

cu,
michael
-- 
It's already too late!

Re: [bug] git-add won't add foo/.git/bar

[Julian Phillips]

On Tue, 25 Mar 2008, Michael Gebetsroither wrote:

> * Junio C Hamano <gitster@pobox.com> wrote:
>> Julian Phillips <julian@quantumfyre.co.uk> writes:
>>> On Tue, 25 Mar 2008, Michael Gebetsroither wrote:
>
>>>> % git-add -f foo/.git/bar
>>>> fatal: unable to add foo/.git/bar to index
>
>> Also it is false that we should only care about the first one.  Think
>> submodules.
>
> Would it be possible to allow it with git-add -f or does that break to
> many cases?

It would be possible, but Junio has convinced me that it wouldn't really 
be wise.  Inside the working tree .git is a special name - end of story.

It would be relatively easy to change the check that prevents you from 
doing it - but this wouldn't stop any of the nasty things that could 
ensue.  You might never have a problem with a simple layout, but it could 
cause mayhem for others with more complicated layouts.

(I've never used any of the more complicated layouts either, which is why 
I didn't initially see the problems ... ho hum)

-- 
Julian

  ---
Hlade's Law:
 	If you have a difficult task, give it to a lazy person --
 	they will find an easier way to do it.

Re: [bug] git-add won't add foo/.git/bar

[Michael Gebetsroither]

* Julian Phillips <julian@quantumfyre.co.uk> wrote:

> It would be relatively easy to change the check that prevents you from 
> doing it - but this wouldn't stop any of the nasty things that could 
> ensue.  You might never have a problem with a simple layout, but it could 
> cause mayhem for others with more complicated layouts.

fair enough, thx :)

cu,
michael
-- 
It's already too late!