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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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


> > * Gitdir = "<Path to base git repository>"
> [...]
> > * Name: <explicit name for this checkout>
> 
> Why use once "key = value", once "key: value" form? Better to stick
> with one. I Would prefer "key = value" one.

Sorry. Typo ;-)


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

I would also be fine with .gitlink looking like some shell script,
defining these variables. However, we need the smart directory
lookup.
And IMHO the keys can be case insensitive as in .git/config.

I am not sure we want to allow the freedom of being able to put any of
GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY, GIT_HEAD_FILE, GIT_REFS_DIRECTORY
in the .gitlink file.

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.

However, for submodules we really _want_ to have fully independent GITDIRs
for each submodule somewhere, and we would have to warn:

 # Warning: if you change one GIT_INDEX, ... in this file, you
 # will screw up the possibility to clone from the GITDIR directory


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

 
> 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

Josef

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]