Re: [RFC] Light-weight checkouts via ".gitlink"

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 8, 2006, 23:24 UTC
Message-ID: <200612090024.17065.jnareb@gmail.com>
In-Reply-To: <200612082354.34488.Josef.Weidendorfer@gmx.de>

Dnia piątek 8. grudnia 2006 23:54, Josef Weidendorfer napisał:

Show 30 quoted lines

> On Friday 08 December 2006 23:18, Jakub Narebski wrote:
>> A few (very few) comments:
>> 
>> Josef Weidendorfer wrote:
>> 
>>> This can be implemented by enhancing git to ignore any subdirectory which
>>> has a file .gitlink in it.
>> 
>> If I remember correctly, while git ignores .git, it does not ignore
>> by default (i.e. without entry in either GIT_DIR/info/excludes, or
>> .gitignore) the directory which has .git directory in it.
> 
> I know. But this is essential. We _have_ to ignore all the files and
> subdirectories in the directory which contains the .gitlink file,
> as these files/subdirectories belong to the submodule.
> 
> There is no other way. You could try to use a special name for the
> whole directory with the light-weight checkout, e.g. ".checkout".
> 
> But then, this is useless for submodules, as for submodules, we want to
> be able to specify the root directory name of the submodule, as that
> is the name which will end up in the tree object of the supermodule.
> 
>> And that should not change for .gitlink. You can always add
>> .gitignore file with * .* patterns in it (ignore all).
> 
> That is not possible:
> .gitignore file has its own meaning inside of the light-weight
> checkout aka submodule, as this directory is the root directory of
> a git checkout.

I have forgot about that. Right.

The only possibility would be to use GIT_DIR/info/excludes with path to submodule, and this conflict with the ability to rename and move submodules.

> AFAIK, Martin's submodule support does it the same, only for directories
> with .git, as he stores the GITDIR directly in the submodule
> checkout.

Ah.

[...]

Show 9 quoted lines

>> GIT_DIR = path to base git repository
>> it is equivalent to setting the following:
>> 
>> GIT_INDEX_FILE = path to index file
>> GIT_OBJECT_DIRECTORY = path to object directory
>> GIT_HEAD_FILE = path to HEAD file
>> GIT_REFS_DIRECTORY = path to refs directory
> 
> AFAIK the latter two do not exist yet, or do they?

They do not exist; perhaps they should for completeness.

[...]

> It is enough if GITDIR and NAME is given. With GITDIR_REAL after the
> smart lookup, e.g. GIT_INDEX_FILE would default to $GITDIR_REAL/external/$NAME
> and so on.

Not $GITDIR_REAL/submodules/<name>/index (or modules instead of submodules)?

Show 6 quoted lines

>> NAME = name
>> should match "name subdirectory" entry in modules file in superproject.
> 
> Yes.
> This would be in my next proposal about how to build the submodule support
> on light-checkouts ;-)

I have thought that with "each submodule as separate repository" approach to submodules the modules file would have module name and either subdirectory in which submodule resides, or GIT_DIR of submodule. And this file could be generated on checkout... which doesn't survive closer scrutiny.

But this would work well with submodules, that's a fact.

Show 19 quoted lines

>> Perhaps instead of adding arbitrary number of .. in front of relative
>> path, we better use some magic, like ... for finding somewhere up?
> 
> I thought about it. But why whould you need it?
> If the value of GITDIR in .gitlink begins with "/", it is an absolute path.
> If not, I think you always want the smart lookup the go upwards, i.e.
> looking for
> 
>   ../<relpath>.git
>   ../../<relpath>.git
>   ../../../<relpath>.git
> 
> So there is no need to add "..." in front of the relative path.
> Or do you see a usecase for
>  rel/path/start/.../rel/path/end
> 
> Ah, yes, I see. Perhaps this makes sense with absolute paths:
> 
> 	/home/user/repos/.../linux

You mean that the above means to check the following paths:

  /home/user/repos/linux
  /home/user/linux
  /home/linux
  /linux

not the searching subdirectories of /home/user/repos for linux directory (there can be many)? BTW web2c implementation of TeX, namely kpathsea(rch) uses // for that, i.e. a//b means b which is somwehere in subdirectories of a.

-- 
Jakub Narebski