Re: Subprojects tasks
- From
- Josef Weidendorfer <josef.weidendorfer@gmx.de>
- Date
- Dec 17, 2006, 00:01 UTC
- Message-ID
- <200612170101.09615.Josef.Weidendorfer@gmx.de>
- In-Reply-To
- <200612170015.24162.jnareb@gmail.com>
On Sunday 17 December 2006 00:15, Jakub Narebski wrote:
Show 15 quoted lines
> Hi! > > Martin Waitz wrote: > > On Sat, Dec 16, 2006 at 07:45:11PM +0100, Jakub Narebski wrote: > >> > >> Or .gitlink file, if we decide to implement it (as lightweight checkout and > >> support for submodules which one can easily move/rename). > > > > I still don't get the advantage of a .gitlink file over an ordinary > > repository with alternates or a symlink. > > Moving or renaming the directory with a submodule. With alternates, > when you rename or move directory with a submodule, you have to add > alternate for new place / new name, or alter existing alternate. > With symlinks you risk broken symlinks.
Yes.
IMHO it simply is added flexibility to allow a checkout to be separate from the .git/ directory, same as explicitly setting $GIT_DIR would do. So this .gitlink file is on the one hand one kind of convenience for users which want to keep their repository separate, yet do not want to specify $GIT_DIR all the time in front of git commands. The .gitlink file simply makes the linkage to the separate repository persistent.
In the scope of submodules, you get the benefit that you can not lose submodule repositories by doing a "rm -rf *" (or similar, e.g. deleting dirs with submodules in it) in the supermodule checkout. Actually, the latter is a valid action: delete a submodule in the next commit; when going back at an earlier commit, the submodule should be there again. So IMHO you allow far more possibilities by separating GITDIR from the checkout of submodules.
However. I think that this .gitlink file proposal can be seen as kind of independent from submodule support at first; it should be easy to make this work together later on. E.g. submodule root directories can be easily detected when they have a .gitlink file (instead of .git/ directory), and so on.
This said, I started implementing it, but do not have anything useful to show yet. Some issues: * Probably, it is better to go with a _file_ .git instead of a file .gitlink, as this way, the user is forced to either go with the git repository in _directory_ .git/ or external linkage with the _file_ ".git". * Even when a .gitlink file is detected, we should honor a $GIT_DIR environment variable set by the user. Unfortunately, $GIT_DIR also can be set by porcelain commands to specify "this command only works in the toplevel directory of a git checkout", i.e. these porcelain commands set GIT_DIR to ".git". IMHO this is a hack, and we explicitly should tell the plumbing about these need e.g. via another environment variable (or a option) without implicitly forcing it by setting $GIT_DIR. * In the way to make the .gitlink file as flexible as possible (and to use it for lightweight checkouts), it really should support $GIT_HEAD_FILE, which would replace "HEAD" with the content of $GIT_HEAD_FILE. E.g. with GIT_HEAD_FILE=MYHEAD, the command "git log HEAD" really should internally work as "git log MYHEAD" (ie. use the .git/MYHEAD file instead). It is arguable whether the usage of "ORIG_HEAD" by the user or in porcelain should map to file "ORIG_MYHEAD". Probably not. However, changing this in all places is some work, and I assume that therefore nobody has ever implemented $GIT_HEAD_FILE - which IMHO really would be useful by itself.