On Friday 08 December 2006 23:18, Jakub Narebski wrote: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. 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. Sorry. Typo ;-) 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 Yes. This would be in my next proposal about how to build the submodule support on light-checkouts ;-) 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Adrian Bunk | [1/6] 2.6.21-rc2: known regressions |
| Paul Jackson | Re: cpuset-remove-sched-domain-hooks-from-cpusets |
git: | |
| Linus Torvalds | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Andrew Morton | Re: [BUG] New Kernel Bugs |
