{"thread":{"id":"43139","subject":"Re: [RFC] Light-weight checkouts via \".gitlink\"","startedAt":"2006-12-08T21:52:31Z","lastAt":"2006-12-09T01:46:20Z","messageCount":8,"participants":["Josef Weidendorfer","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"294856","messageId":"200612082252.31245.Josef.Weidendorfer@gmx.de","threadId":"43139","inReplyTo":null,"subject":"[RFC] Light-weight checkouts via \".gitlink\"","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-08T21:52:31Z","receivedAt":"2006-12-08T21:52:31Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"Hi,\n\nwhen I recently thought about submodule support, I had the\nidea that it is easier to get it by going in small,\nincremental steps, introducing usefull subfeatures on their\non while on it.\n\nThe following is one outcome of this, a proposal for\nlight-weight checkouts of git branches, without the need\nto have to full repository in a .git subdirectory, but\nthe just have a file .gitlink is simple as possible, which\nmanages the link to the real repository.\n\nOf course, this feature is tailored to support checkouts of\nsubmodules as being such light-weight checkouts themself.\nThe current proposal just says that light-weight checkouts\nshould be ignored when existing inside of another checkout.\nFor real submodule support, we would want to be able the\ndo a \"git add\" on these light-weight checkouts (which of\ncourse are bound to some commit), and on \"git commit\", this\nwould add a \"submodule object\" at this place into the tree\nof the outer repository.\n\nComments?\n\nJosef\n\n\n============================================================\n\nSupport for multiple external light-weight checkouts\naka \".gitlink\" proposal\n\n\nMain ideas behind light-weight checkouts\n----------------------------------------\n\nMake submodules easier to implement by separating\npart of the needed infrastructure into a independent,\nyet useful feature\n\n(1) Allow to separate a branch checkout from its repository location\non the local filesystem. This minimally needs to be only _one_ file,\ncalled \".gitlink\" here. One should be able to move the\ncheckout directory around (within some limits) without breaking\nthe link to its \"base\" repository.\n\nWe want this later for submodule checkouts inside of a supermodule\ncheckout: (a) to not loose the objects+index+HEAD if the user\nremoves the whole checkout to remove the submodule in next\nsupermodule commit; (b) to allow for moving submodules around\nbetween supermodule commits.\n\nThis can be implemented with a small script reading .gitlink and setting\nup $GITDIR and $GIT_INDEX_FILE accordingly. However, there should be\na further environment variable to use a file for HEAD ($GIT_HEAD_FILE?).\nInterpretation of the link to the base directory has to be a little smart,\nie. by prefixing a relative path with as many \"..\" as needed to find a\ngit repository.\n\n(2) Light-weight checkouts should work inside of another\ncheckout, be it a normal or a light-weight checkout itself.\nThe subdirectory of the light-weight checkout has to be ignored\nin the outer checkout (at least by default).\n\nThis is needed to be able to use light-weight checkouts for submodels,\nas these should be checked out inside of another checkout (even\ninside of another submodule checkout for hierarchical submodules).\n\nThis can be implemented by enhancing git to ignore any subdirectory which\nhas a file .gitlink in it.\n\n\nExample usage\n-------------\n\nKeep a checkout of the todo branch of git.git inside of the checkout of\nany other branch (or fully outside). You should be able to use all the normal\ngit commands inside of this directory (commit etc).\nSomething like inside of e.g. a master checkout of git.git:\n\n make todo\n cd todo\n touch .gitlink\n git checkout todo\n\nThe .gitlink file can be empty in this case when we make the smart lookup of\nthe base repository do the right thing with a default of an emtpy relative path.\n\nAnother usage is to keep all your git repositories (looking like bare ones)\nin one place, e.g. below $HOME/git-repositories/, and have the the checkouts\nyou are working in at another place, without the need for setting $GITDIR etc\nfor this.\n\n\nSome thoughts about implementation\n----------------------------------\n\nAs we need our own index and HEAD for any light-weight checkout, we\ncan choose a subdirectory of .git of the base repository to store a full,\nindependent working GITDIR on its own. It would default to linking the\nobjects and refs namespace to the base repository, but for submodules,\nit *can* have its own object database and refs namespace; it just would\nbe locateable via the GITDIR of the base repository.\n\n\"Locateable\" means that we need a name for different light-weight\ncheckouts. The name can be determined from the relative position of\nthe light-weight checkout to its base repository, or could be fixed\nand specified in the .gitlink file.\n\nExample for an light-weight checkout with name \"mywork\", linking to\nthe (bare) base repository \"base\":\n\n base.git/external/mywork/HEAD\n base.git/external/mywork/index\n base.git/external/mywork/refs -> ../../../refs\n base.git/external/mywork/objects -> ../../../objects\n\nA light-weight checkout in a sibling directory to base.git needs\nthe relative path to its own .git directory:\n\"../base.git/external/mywork\".\n\nThis can be split up in two things:\n- relative path to base repository\n- a name for this light-weight checkout\nOne has to be able to get this out of the content of the .gitlink file.\n\n\nProposal for .gitlink entries (one line per entry)\n--------------------------------------------------\n\n* Gitdir = \"<Path to base git repository>\"\n\nOptional.\nAn absolute or relative path to the base git repository.\nWith relative path, a heuristic is used to find the\ngit directory: the path will be prefixed by as\nmany \"../\" as needed, and \".git\" or .gitlink appended.\nThe value defaults to an empty relative path, which\nwill check all parent directories for a .git subdirectory.\n\n* Name: <explicit name for this checkout>\n\nOptional.\nGit uses this name to find its own GITDIR in the GITDIR\nof the base repository. If not specified, the name defaults\nto the relative path of the light-weight checkout from\nthe base directory, stripping any \"..\" in front.\n\n\n\nFor the \"mywork\" example above, we could have a checkout\ndirectory, sibling to \"base.git\" and called \"mywork\".\nFor the .gitlink file inside, it is enough to specify\n\n Gitdir = base\n\nBecause the search heuristic will find the base repository\nat real relative path \"../base.git\". Further, relative\npath of the checkout from the base repository is \"../mywork\",\ngiving the name \"mywork\".\n\nWhen moving the checkout into another directory, it's name\nwould change if not explicitly specified in the .gitlink\nfile. For submodules, this could be the wanted semantic.\nHowever, with changing name, we have possibly lost our\nindex and HEAD.\nA solution for this could be to always store a copy of HEAD\ninto .gitlink, or even have a \"Head:\" .gitlink entry itself\nas HEAD.\n\n============================================================\n"},{"id":"295958","messageId":"elco6p$uku$1@sea.gmane.org","threadId":"43139","inReplyTo":"200612082252.31245.Josef.Weidendorfer@gmx.de","subject":"Re: [RFC] Light-weight checkouts via \".gitlink\"","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-08T22:18:12Z","receivedAt":"2006-12-08T22:18:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"A few (very few) comments:\n\nJosef Weidendorfer wrote:\n\n> This can be implemented by enhancing git to ignore any subdirectory which\n> has a file .gitlink in it.\n\nIf I remember correctly, while git ignores .git, it does not ignore\nby default (i.e. without entry in either GIT_DIR/info/excludes, or\n.gitignore) the directory which has .git directory in it.\n\nAnd that should not change for .gitlink. You can always add\n.gitignore file with * .* patterns in it (ignore all).\n \n> * Gitdir = \"<Path to base git repository>\"\n[...]\n> * Name: <explicit name for this checkout>\n\nWhy use once \"key = value\", once \"key: value\" form? Better to stick\nwith one. I Would prefer \"key = value\" one.\n\nGIT_DIR = path to base git repository\nit is equivalent to setting the following:\n\nGIT_INDEX_FILE = path to index file\nGIT_OBJECT_DIRECTORY = path to object directory\nGIT_HEAD_FILE = path to HEAD file\nGIT_REFS_DIRECTORY = path to refs directory\n\nNAME = name\nshould match \"name subdirectory\" entry in modules file in superproject.\n\n\nPerhaps instead of adding arbitrary number of .. in front of relative\npath, we better use some magic, like ... for finding somewhere up?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"293906","messageId":"200612082354.34488.Josef.Weidendorfer@gmx.de","threadId":"43139","inReplyTo":"elco6p$uku$1@sea.gmane.org","subject":"Re: [RFC] Light-weight checkouts via \".gitlink\"","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-08T22:54:34Z","receivedAt":"2006-12-08T22:54:34Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 08 December 2006 23:18, Jakub Narebski wrote:\n> A few (very few) comments:\n> \n> Josef Weidendorfer wrote:\n> \n> > This can be implemented by enhancing git to ignore any subdirectory which\n> > has a file .gitlink in it.\n> \n> If I remember correctly, while git ignores .git, it does not ignore\n> by default (i.e. without entry in either GIT_DIR/info/excludes, or\n> .gitignore) the directory which has .git directory in it.\n\nI know. But this is essential. We _have_ to ignore all the files and\nsubdirectories in the directory which contains the .gitlink file,\nas these files/subdirectories belong to the submodule.\n\nThere is no other way. You could try to use a special name for the\nwhole directory with the light-weight checkout, e.g. \".checkout\".\n\nBut then, this is useless for submodules, as for submodules, we want to\nbe able to specify the root directory name of the submodule, as that\nis the name which will end up in the tree object of the supermodule.\n\n> And that should not change for .gitlink. You can always add\n> .gitignore file with * .* patterns in it (ignore all).\n\nThat is not possible:\n.gitignore file has its own meaning inside of the light-weight\ncheckout aka submodule, as this directory is the root directory of\na git checkout.\n\nAFAIK, Martin's submodule support does it the same, only for directories\nwith .git, as he stores the GITDIR directly in the submodule\ncheckout.\n\n\n> > * Gitdir = \"<Path to base git repository>\"\n> [...]\n> > * Name: <explicit name for this checkout>\n> \n> Why use once \"key = value\", once \"key: value\" form? Better to stick\n> with one. I Would prefer \"key = value\" one.\n\nSorry. Typo ;-)\n\n\n> GIT_DIR = path to base git repository\n> it is equivalent to setting the following:\n> \n> GIT_INDEX_FILE = path to index file\n> GIT_OBJECT_DIRECTORY = path to object directory\n> GIT_HEAD_FILE = path to HEAD file\n> GIT_REFS_DIRECTORY = path to refs directory\n\nAFAIK the latter two do not exist yet, or do they?\n\nI would also be fine with .gitlink looking like some shell script,\ndefining these variables. However, we need the smart directory\nlookup.\nAnd IMHO the keys can be case insensitive as in .git/config.\n\nI am not sure we want to allow the freedom of being able to put any of\nGIT_INDEX_FILE, GIT_OBJECT_DIRECTORY, GIT_HEAD_FILE, GIT_REFS_DIRECTORY\nin the .gitlink file.\n\nIt is enough if GITDIR and NAME is given. With GITDIR_REAL after the\nsmart lookup, e.g. GIT_INDEX_FILE would default to $GITDIR_REAL/external/$NAME\nand so on.\n\nHowever, for submodules we really _want_ to have fully independent GITDIRs\nfor each submodule somewhere, and we would have to warn:\n\n # Warning: if you change one GIT_INDEX, ... in this file, you\n # will screw up the possibility to clone from the GITDIR directory\n\n\n> NAME = name\n> should match \"name subdirectory\" entry in modules file in superproject.\n\nYes.\nThis would be in my next proposal about how to build the submodule support\non light-checkouts ;-)\n\n \n> Perhaps instead of adding arbitrary number of .. in front of relative\n> path, we better use some magic, like ... for finding somewhere up?\n\nI thought about it. But why whould you need it?\nIf the value of GITDIR in .gitlink begins with \"/\", it is an absolute path.\nIf not, I think you always want the smart lookup the go upwards, i.e.\nlooking for\n\n  ../<relpath>.git\n  ../../<relpath>.git\n  ../../../<relpath>.git\n\nSo there is no need to add \"...\" in front of the relative path.\nOr do you see a usecase for\n rel/path/start/.../rel/path/end\n\nAh, yes, I see. Perhaps this makes sense with absolute paths:\n\n\t/home/user/repos/.../linux\n\nJosef\n"},{"id":"294794","messageId":"200612090024.17065.jnareb@gmail.com","threadId":"43139","inReplyTo":"200612082354.34488.Josef.Weidendorfer@gmx.de","subject":"Re: [RFC] Light-weight checkouts via \".gitlink\"","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-08T23:24:16Z","receivedAt":"2006-12-08T23:24:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia piątek 8. grudnia 2006 23:54, Josef Weidendorfer napisał:\n> On Friday 08 December 2006 23:18, Jakub Narebski wrote:\n>> A few (very few) comments:\n>> \n>> Josef Weidendorfer wrote:\n>> \n>>> This can be implemented by enhancing git to ignore any subdirectory which\n>>> has a file .gitlink in it.\n>> \n>> If I remember correctly, while git ignores .git, it does not ignore\n>> by default (i.e. without entry in either GIT_DIR/info/excludes, or\n>> .gitignore) the directory which has .git directory in it.\n> \n> I know. But this is essential. We _have_ to ignore all the files and\n> subdirectories in the directory which contains the .gitlink file,\n> as these files/subdirectories belong to the submodule.\n> \n> There is no other way. You could try to use a special name for the\n> whole directory with the light-weight checkout, e.g. \".checkout\".\n> \n> But then, this is useless for submodules, as for submodules, we want to\n> be able to specify the root directory name of the submodule, as that\n> is the name which will end up in the tree object of the supermodule.\n> \n>> And that should not change for .gitlink. You can always add\n>> .gitignore file with * .* patterns in it (ignore all).\n> \n> That is not possible:\n> .gitignore file has its own meaning inside of the light-weight\n> checkout aka submodule, as this directory is the root directory of\n> a git checkout.\n\nI have forgot about that. Right.\n\nThe only possibility would be to use GIT_DIR/info/excludes with path\nto submodule, and this conflict with the ability to rename and move\nsubmodules.\n\n> AFAIK, Martin's submodule support does it the same, only for directories\n> with .git, as he stores the GITDIR directly in the submodule\n> checkout.\n\nAh. \n\n[...]\n>> GIT_DIR = path to base git repository\n>> it is equivalent to setting the following:\n>> \n>> GIT_INDEX_FILE = path to index file\n>> GIT_OBJECT_DIRECTORY = path to object directory\n>> GIT_HEAD_FILE = path to HEAD file\n>> GIT_REFS_DIRECTORY = path to refs directory\n> \n> AFAIK the latter two do not exist yet, or do they?\n\nThey do not exist; perhaps they should for completeness.\n\n[...] \n> It is enough if GITDIR and NAME is given. With GITDIR_REAL after the\n> smart lookup, e.g. GIT_INDEX_FILE would default to $GITDIR_REAL/external/$NAME\n> and so on.\n\nNot $GITDIR_REAL/submodules/<name>/index (or modules instead of\nsubmodules)?\n\n>> NAME = name\n>> should match \"name subdirectory\" entry in modules file in superproject.\n> \n> Yes.\n> This would be in my next proposal about how to build the submodule support\n> on light-checkouts ;-)\n\nI have thought that with \"each submodule as separate repository\" approach\nto submodules the modules file would have module name and either\nsubdirectory in which submodule resides, or GIT_DIR of submodule. And\nthis file could be generated on checkout... which doesn't survive closer\nscrutiny.\n\nBut this would work well with submodules, that's a fact.\n  \n>> Perhaps instead of adding arbitrary number of .. in front of relative\n>> path, we better use some magic, like ... for finding somewhere up?\n> \n> I thought about it. But why whould you need it?\n> If the value of GITDIR in .gitlink begins with \"/\", it is an absolute path.\n> If not, I think you always want the smart lookup the go upwards, i.e.\n> looking for\n> \n>   ../<relpath>.git\n>   ../../<relpath>.git\n>   ../../../<relpath>.git\n> \n> So there is no need to add \"...\" in front of the relative path.\n> Or do you see a usecase for\n>  rel/path/start/.../rel/path/end\n> \n> Ah, yes, I see. Perhaps this makes sense with absolute paths:\n> \n> \t/home/user/repos/.../linux\n\nYou mean that the above means to check the following paths:\n\n  /home/user/repos/linux\n  /home/user/linux\n  /home/linux\n  /linux\n\nnot the searching subdirectories of /home/user/repos for linux\ndirectory (there can be many)? BTW web2c implementation of TeX,\nnamely kpathsea(rch) uses // for that, i.e. a//b means b which\nis somwehere in subdirectories of a.\n-- \nJakub Narebski\n"},{"id":"294417","messageId":"200612090025.24234.Josef.Weidendorfer@gmx.de","threadId":"43139","inReplyTo":"200612082354.34488.Josef.Weidendorfer@gmx.de","subject":"Re: [RFC] Light-weight checkouts via \".gitlink\"","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-08T23:25:24Z","receivedAt":"2006-12-08T23:25:24Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 08 December 2006 23:54, Josef Weidendorfer wrote:\n> > NAME = name\n\nForgot to mention in the proposal:\nIf you recursively have light-weight checkouts inside each other,\nthe real \"name\" (for .git/external/<name/ and for further submodule\nconfiguration e.g. in .git/modules of the base repository)\nshould of course be the concatenation of the names in the .gitlink\nfiles while going up to the base repository.\n\n> > Perhaps instead of adding arbitrary number of .. in front of relative\n> > path, we better use some magic, like ... for finding somewhere up?\n\nNo need. Something like\n\n> \t/home/user/.../linux\n\nis crazy. Do you want to scan all of your home directory everytime this\nlookup is needed? So \"...\" really only makes sense in front of the\nrelative path, but there, you also can leave it out.\n\n"},{"id":"298137","messageId":"200612090040.17169.Josef.Weidendorfer@gmx.de","threadId":"43139","inReplyTo":"200612090024.17065.jnareb@gmail.com","subject":"Re: [RFC] Light-weight checkouts via \".gitlink\"","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-08T23:40:17Z","receivedAt":"2006-12-08T23:40:17Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Saturday 09 December 2006 00:24, Jakub Narebski wrote:\n> > That is not possible:\n> > .gitignore file has its own meaning inside of the light-weight\n> > checkout aka submodule, as this directory is the root directory of\n> > a git checkout.\n> \n> I have forgot about that. Right.\n> \n> The only possibility would be to use GIT_DIR/info/excludes with path\n> to submodule, and this conflict with the ability to rename and move\n> submodules.\n\nYes. This whole .gitlink thing more or less is about trying to\navoid as far as possible any path configuration in the supermodule\nwhich would have to be changed when the user moves or even deletes\nthe submodule. Exactly for the latter, we want the GITDIR for submodules\nbetter be separate.\n\n> >> GIT_DIR = path to base git repository\n> >> it is equivalent to setting the following:\n> >> \n> >> GIT_INDEX_FILE = path to index file\n> >> GIT_OBJECT_DIRECTORY = path to object directory\n> >> GIT_HEAD_FILE = path to HEAD file\n> >> GIT_REFS_DIRECTORY = path to refs directory\n> > \n> > AFAIK the latter two do not exist yet, or do they?\n> \n> They do not exist; perhaps they should for completeness.\n\nActually, I am fine with allowing them in .gitlink. This makes\nthe whole thing much more flexible.\n\n> [...] \n> > It is enough if GITDIR and NAME is given. With GITDIR_REAL after the\n> > smart lookup, e.g. GIT_INDEX_FILE would default to $GITDIR_REAL/external/$NAME\n> > and so on.\n> \n> Not $GITDIR_REAL/submodules/<name>/index (or modules instead of\n> submodules)?\n\nOoops, yes.\nI am not actually sure what's the best name here: \"external\", \"submodule\", ... ?\nI thought the the SVN name also fits for the submodule case. The submodule\nis independent, and possibliy comes from an external git repository.\n\n> >> NAME = name\n> >> should match \"name subdirectory\" entry in modules file in superproject.\n> > \n> > Yes.\n> > This would be in my next proposal about how to build the submodule support\n> > on light-checkouts ;-)\n> \n> I have thought that with \"each submodule as separate repository\" approach\n> to submodules the modules file would have module name and either\n> subdirectory in which submodule resides, or GIT_DIR of submodule. And\n> this file could be generated on checkout... which doesn't survive closer\n> scrutiny.\n\nOf course, that is a more simple approach. But I think the .gitlink thing\nreally is more flexible without being more complex.\n\n> > Ah, yes, I see. Perhaps this makes sense with absolute paths:\n> > \n> > \t/home/user/repos/.../linux\n> \n> You mean that the above means to check the following paths:\n> \n>   /home/user/repos/linux\n>   /home/user/linux\n>   /home/linux\n>   /linux\n\nNo.\n\n> not the searching subdirectories of /home/user/repos for linux\n> directory (there can be many)?\n\nYes. But you can scratch this.\n\n"},{"id":"296255","messageId":"200612090053.48186.jnareb@gmail.com","threadId":"43139","inReplyTo":"200612090025.24234.Josef.Weidendorfer@gmx.de","subject":"Re: [RFC] Light-weight checkouts via \".gitlink\"","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-08T23:53:47Z","receivedAt":"2006-12-08T23:53:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Josef Weidendorfer wrote:\n> On Friday 08 December 2006 23:54, Josef Weidendorfer wrote:\n>> Jakub Narebski wrote:\n>>> NAME = name\n> \n> Forgot to mention in the proposal:\n> If you recursively have light-weight checkouts inside each other,\n> the real \"name\" (for .git/external/<name/ and for further submodule\n> configuration e.g. in .git/modules of the base repository)\n> should of course be the concatenation of the names in the .gitlink\n> files while going up to the base repository.\n\nWhy concatenation? I thought the name would be ID of submodule,\nand should be just somehow unique.\n\nAnd if concatenation, pehaps some forbidden character inserted between\nthem? Like '/' for example ;-)\n \n>>> Perhaps instead of adding arbitrary number of .. in front of\n>>> relative path, we better use some magic, like ... for finding\n>>> somewhere up? \n> \n> No need. Something like\n> \n>> \t/home/user/.../linux\n> \n> is crazy. Do you want to scan all of your home directory everytime\n> this  lookup is needed? So \"...\" really only makes sense in front of\n> the relative path, but there, you also can leave it out.\n\nNo. I meant /home/user/.../linux to mean searching for\n  /home/user/linux\n  /home/linux\n  /linux\nbut I don't think it is useful. As to relative path matching in any\nparent directory... well, that differs only in direction (up instead of \ndown) in matching filename in .gitignore when path does not contain /\n(well, actually it is taken as fileglob).\n-- \nJakub Narebski\n"},{"id":"294574","messageId":"200612090246.20770.Josef.Weidendorfer@gmx.de","threadId":"43139","inReplyTo":"200612090053.48186.jnareb@gmail.com","subject":"Re: [RFC] Light-weight checkouts via \".gitlink\"","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-09T01:46:20Z","receivedAt":"2006-12-09T01:46:20Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Saturday 09 December 2006 00:53, Jakub Narebski wrote:\n> Josef Weidendorfer wrote:\n> > On Friday 08 December 2006 23:54, Josef Weidendorfer wrote:\n> >> Jakub Narebski wrote:\n> >>> NAME = name\n> > \n> > Forgot to mention in the proposal:\n> > If you recursively have light-weight checkouts inside each other,\n> > the real \"name\" (for .git/external/<name/ and for further submodule\n> > configuration e.g. in .git/modules of the base repository)\n> > should of course be the concatenation of the names in the .gitlink\n> > files while going up to the base repository.\n> \n> Why concatenation? I thought the name would be ID of submodule,\n> and should be just somehow unique.\n> \n> And if concatenation, pehaps some forbidden character inserted between\n> them? Like '/' for example ;-)\n\nYes, you are right.\nNesting of submodules really is an important issue. The .gitlink\nfile allows us to put the submodule GITDIR somewhere in the supermodul's\nGITDIR. The idea is that you can clone the submodule GITDIR if you\nwant. With submodule \"inner\" nesting inside of  submodule \"outer\", \nthe GITDIR of \"outer\" should have the GITDIR of inner inside to allow\nfor cloning \"outer\" together with its submodule \"inner\".\n\nSo it is not enough to have a submodule \"outer\" and a submodule\n\"outer/inner\" in the supermodule. We want\n\n\tsuper.git/ext/outer.git/\n\nto be the GITDIR for submodule \"outer\", and inside \n\n\tsuper.git/ext/outer.git/ext/inner.git\n.\n\nActually, it would be nice if this .gitlink proposal did not have to\ndeal with it. Instead, a .gitlink should be so flexible to allow such\nnesting if needed. \n\n"}]}