From: Jakub Narebski <jnareb@gmail•com>
To: Josef Weidendorfer <Josef.Weidendorfer@gmx•de>
Cc: git@vger•kernel.org
Subject: Re: [RFC] Light-weight checkouts via ".gitlink"
Date: Sat, 9 Dec 2006 00:24:16 +0100 [thread overview]
Message-ID: <200612090024.17065.jnareb@gmail.com> (raw)
In-Reply-To: <200612082354.34488.Josef.Weidendorfer@gmx.de>
Dnia piątek 8. grudnia 2006 23:54, Josef Weidendorfer napisał:
> 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.
[...]
>> 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)?
>> 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.
>> 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
next prev parent reply other threads:[~2006-12-08 23:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-08 21:52 [RFC] Light-weight checkouts via ".gitlink" Josef Weidendorfer
2006-12-08 22:18 ` Jakub Narebski
2006-12-08 22:54 ` Josef Weidendorfer
2006-12-08 23:24 ` Jakub Narebski [this message]
2006-12-08 23:40 ` Josef Weidendorfer
2006-12-08 23:25 ` Josef Weidendorfer
2006-12-08 23:53 ` Jakub Narebski
2006-12-09 1:46 ` Josef Weidendorfer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200612090024.17065.jnareb@gmail.com \
--to=jnareb@gmail$(echo .)com \
--cc=Josef.Weidendorfer@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox