{"thread":{"id":"8181","subject":"[0/4] What's not in 1.5.2 (overview)","startedAt":"2007-05-16T22:47:12Z","lastAt":"2007-05-25T09:55:35Z","messageCount":55,"participants":["Junio C Hamano","Andy Parkins","Alex Riesen","Petr Baudis","Nicolas Pitre","Jeff King","Michael S. Tsirkin","Josef Weidendorfer","Steven Grimm","Johannes Sixt","Jakub Narebski","Aidan Van Dyk","Julian Phillips","Torgil Svensson","Sven Verdoolaege"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"42341","messageId":"11793556363795-git-send-email-junkio@cox.net","threadId":"8181","inReplyTo":null,"subject":"[0/4] What's not in 1.5.2 (overview)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-16T22:47:12Z","receivedAt":"2007-05-16T22:47:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Upcoming release 1.5.2 is nearing completion, so let's look at\nthe issues that are specifically excluded from it.\n\nBefore listing topics there is one thing.\n\n* sp/cvsexport (Thu May 10 01:06:36 2007 +0200) 1 commit\n + Optimized cvsexportcommit: calling 'cvs status' once instead of\n once per touched file.\n\nThis should really be 1.5.2. Real-world users of cvsexport, if\nyou were burned by this, please NAK as soon as possible. I'll\nmerge it to 1.5.2 unless I hear from anybody in a day or two.\n\nThe messages that follow this are:\n\n [1/4] Easy-to-decide ones; what's been cooking in next.\n [2/4] The ones to be cooked in next after 1.5.2\n [3/4] Things we do not have code for yet.\n [4/4] Leftover bits\n"},{"id":"42342","messageId":"11793556371446-git-send-email-junkio@cox.net","threadId":"8181","inReplyTo":"11793556363795-git-send-email-junkio@cox.net","subject":"[1/4] What's not in 1.5.2 (have been cooking in next)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-16T22:47:13Z","receivedAt":"2007-05-16T22:47:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the first batch that will be in 'master' after 1.5.2\nhappens.\n\nThey all have been cooking in 'next', or were not compelling\nenough feature enhancements to be included after -rc1.\n\n* jb/statcolor (Sat May 5 16:48:54 2007 -0400) 1 commit\n + Add colour support in rebase and merge tree diff stats output.\n\n* tt/gc (Wed May 9 15:48:39 2007 -0400) 1 commit\n + Add --aggressive option to 'git gc'\n\n* np/pack (Wed May 9 14:42:42 2007 -0400) 3 commits\n + deprecate the new loose object header format\n + make \"repack -f\" imply \"pack-objects --no-reuse-object\"\n + allow for undeltified objects not to be reused.\n\n* sv/checkout (Wed May 9 12:33:20 2007 +0200) 1 commit\n + git-update-ref: add --no-deref option for overwriting/detaching\n ref\n\n* mst/connect (Wed May 16 20:09:41 2007 +0300) 1 commit\n + connect: display connection progress\n\n* dh/pack (Wed May 9 13:56:50 2007 -0700) 3 commits\n + Custom compression levels for objects and packs\n + make \"repack -f\" imply \"pack-objects --no-reuse-object\"\n + allow for undeltified objects not to be reused\n"},{"id":"42343","messageId":"11793556372693-git-send-email-junkio@cox.net","threadId":"8181","inReplyTo":"11793556363795-git-send-email-junkio@cox.net","subject":"[2/4] What's not in 1.5.2 (will cook in next)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-16T22:47:14Z","receivedAt":"2007-05-16T22:47:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"These have been cooking in 'pu'; will be in 'next' after 1.5.2\nhappens.\n\n* db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits\n . Update local tracking refs when pushing\n . Add handlers for fetch-side configuration of remotes.\n . Move refspec parser from connect.c and cache.h to remote.{c,h}\n . Move remote parsing into a library file out of builtin-push.\n + git-update-ref: add --no-deref option for overwriting/detaching\n ref\n\nThis was rebased on to Sven's change to lock_any_ref_for_update();\n\n* dh/repack (Sun May 13 12:47:09 2007 -0700) 9 commits\n . git-repack --max-pack-size: add option parsing to enable feature\n . git-repack --max-pack-size: split packs as asked by\n write_{object,one}()\n . git-repack --max-pack-size: write_{object,one}() respect pack\n limit\n . git-repack --max-pack-size: new file statics and code\n restructuring\n . Alter sha1close() 3rd argument to request flush only\n + Custom compression levels for objects and packs\n + deprecate the new loose object header format\n + make \"repack -f\" imply \"pack-objects --no-reuse-object\"\n + allow for undeltified objects not to be reused\n\nThis follows the \"custom compression levels\" series from the\nsame author.\n"},{"id":"42345","messageId":"11793556371774-git-send-email-junkio@cox.net","threadId":"8181","inReplyTo":"11793556363795-git-send-email-junkio@cox.net","subject":"[3/4] What's not in 1.5.2 (new topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-16T22:47:15Z","receivedAt":"2007-05-16T22:47:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are random things that I'd like to see happen during 1.5.3\ncycle.\n\n * git-clone should become a very thin wrapper around\n init/remote/fetch/checkout.\n\n - it may be necessary to teach git-remote about --bare\n layout.\n\n - by getting rid of 'fetch' logic from git-clone as much as\n possible, it would hopefully become easier to freeze what\n git-fetch needs to do and help rewriting the latter in C.\n\n - update native protocol with an extension to carry which\n branch HEAD (or any symref) points at, instead of guessing.\n We already know this information when clone is done over\n HTTP, but we are discarding that information in git-clone\n for the sake of implementation simplicity and having it\n also guess.\n\n * more superproject support in Porcelain-ish.\n\n - superproject support in Porcelain-ish is mostly about\n checking things out. One possible scenario:\n\n\t$ git clone --recursive $url_of_superproject\n\n may instruct \"clone that, and also clone any projects that\n the superproject uses, and check everything out\". I would\n imagine that lThis would be carried out in the following\n steps.\n\n (1) The usual \"git-clone\" dance, determining the directory\n name to create, running mkdir and init-db, setting up\n tracking refspec specification in the config, and\n running the initial fetch.\n\n (2) Because the command was not given '-n' (\"do not\n checkout\"), HEAD is checked out. git-checkout notices\n that there are commits bound to some directories in its\n tree.\n\n (3) git-checkout finds there is .gitmodules file in the\n tree (and the checked-out working file), which\n describes these subprojects. It looks at the config\n and notices that it does not yet know about them\n (obviously this is true, as this is the first checkout\n after clone, but I am trying to outline how checkout\n after a merge should work in the general case).\n\n\t It determines where to fetch that subproject from,\n\t perhaps it uses the default URL described in\n\t .gitmodules file to, while asking the user for\n\t confirmation and giving the user a chance to override\n\t it. And it records something in the config -- now that\n\t project is known to this repository.\n\n (4) git-checkout then calls git-clone recursively in that\n subdirectory for the subproject (which may further\n contain subprojects of its own, but that would\n naturally work).\n\n - Another scenario, after \"git clone\" of the superproject\n _without_ the above \"--recursive\" behaviour. There needs\n to be a way to later clone and checkout a named subproject\n (and that subproject alone). Perhaps\n\n\t$ git checkout --populate-subproject subdir\n\n would notice that subdir corresponds to a subproject that\n is \"not known\" to this repository.\n\n\t I am assuming .gitmodules from the upstream describes it,\n\t but the default is not to recurse into any subproject,\n\t which would leave the subdir _without_ its own .git\n\t directory. A subproject becomes \"known\" to your repository\n\t when you tell git that you care about it (e.g. \"clone\n\t --recursive\" above), and that decision would be recorded\n\t somewhere in .git/config of the superproject. .gitmodules\n\t would give the default URL and probably the branch to\n\t follow. The URL definitely needs to be overridable by\n\t per-repository configuration as network reachability would\n\t be different for everybody; I am not sure about the need to\n\t make it overridable which branch the subproject should\n\t follow, but my gut feeling is that we do not have to.\n\n Then it does the same as (3) and (4) in \"clone --reference\"\n above (in fact, I am envisioning that that scenario would\n call \"git checkout --populate-subproject\" in those steps).\n\n - We might want to have a way to tell it to stop tracking an\n already \"known\" subproject, which means that the section in\n .git/config that would track the status of the subproject\n (e.g. \"is it known\", \"what's the URL\", etc.) needs another\n variable that says \"are we still interested in it?\".\n\n - There may be obvious \"frills\" we would want to eventually\n have, such as defaulting the repository to find the\n subproject that corresponds to subdir/ to $URL/subdir (iow\n if http://repo.or.cz/cgit.git binds git.git at its src/\n directory, we would expect that the repository to house\n that subproject is found at http://repo.or/cz/cgit.git/src\n by default), but during the first round, I think it is\n better to leave things explicit. So, for the above\n example, instead of defaulting the $URL/$subdir location,\n always require .gitmodules to say where to fetch the\n subproject from.\n\n - \"git diff\", \"git status\" and friends might want to learn\n recursive behaviour. These should be much easier than any\n of the above.\n\n Note: I am not trying to dictate the overall superproject\n Porcelain design should follow the above literally, but just\n throwing out a strawman. As I do not expect to be a heavy\n user of superproject support myself yet, other people who\n have thought about the problem longer (much longer) than I\n have will certainly have better ideas.\n\n\n * Perhaps add 'tree' entries in the index. This may make the\n current cache-tree extension unnecessary, and I suspect it\n will simplify various paths that deal with D/F conflicts in\n the current codebase.\n\n I suspect this might need 1.6, as it is a one-way backward\n incompatible change for the 'index', but 'index' is local so\n it might not be such a big deal. In the worst case, when the\n users find \"git checkout\" from 1.5.2 does not work in a\n repository checked out with such an updated index format, we\n could ask them to \"rm -f .git/index && git checkout HEAD\".\n\n * make merge-recursive and read-tree -u more robust when D/F\n conflict is involved.\n\n I think that the use of current_{file,directory}_set is\n misguided and it should just ask the index if there are\n conflicts. unpack-trees.c::check_updates() logic probably is\n the right place to deal with what to do with the working tree\n when the merge result contains D/F conflicts (i.e.\n merge-recursive wants to create file~branchname instead of\n not touching the working tree).\n"},{"id":"42344","messageId":"11793556383977-git-send-email-junkio@cox.net","threadId":"8181","inReplyTo":"11793556363795-git-send-email-junkio@cox.net","subject":"[4/4] What's not in 1.5.2 (other bits and pieces)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-16T22:47:16Z","receivedAt":"2007-05-16T22:47:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the leftover pieces I have in todo:TODO file that I did\nnot mention in the earlier messages. I left them out from the\nthird message of this series, as (1) some are more of \"trivial\nfix\" category, and (2) others are heavier and would probably not\nfit for a single release cycle such as 1.5.3.\n\nThe easier ones\n---------------\n\n* parse-remote.sh has POSIXLY incorrect shell construct.\n\nMessage-ID: <20070505080313.GA12170@gondor.apana.org.au>\n\n* Use 'git diff' not 'git diff-tree' in merge and rebase\n\nFrom: James Bowes \nMessage-ID: <1178398134288-git-send-email-jbowes@dangerouslyinc.com>\n\n* gitk --left-right\n\nFrom: Linus Torvalds \nMessage-ID: \nFrom: Junio C Hamano \nMessage-ID: <7vabwifl23.fsf@assigned-by-dhcp.cox.net>\n\n* Handling pushing into non-bare repository more gracefully.\n\nWhen git-push is done to a non-bare repository and updates the\nbranch that is currently checked out, we currently do not do\nanything special.\n\nFrom: Linus Torvalds \nMessage-ID: \n\n* git-daemon bug?\n\nFrom: Franck Bui-Huu \nMessage-ID: <450EABD0.1040102@innova-card.com>\n\nRepeated requests against git-daemon makes it stuck under --syslog\n\n[jc: does not reproduce easily for me; has anybody seen it?]\n\n* AsciiDoc 8 would break our documentation.\n\nFrom: Stefan Richter \nMessage-ID: <4523EC14.6070806@s5r6.in-berlin.de>\n\nAsciiDoc 8 does not grok documents written for AsciiDoc 7 out of\nthe box.\n\n[jc: limbo?]\n\n* Delegate gitweb part to somebody else.\n\n* Use gitattributes for more things.\n\n - 'precious' files that are not tracked but not\n build-products. Currently people seem to put them in\n .gitignore, but that is not quite right, as .gitignore is\n meant for ignoring things that can be lost (build products,\n editor backup files). \"git clean -x\" and \"git checkout\" to\n another branch that has a file where the current branch has a\n directory could lose such 'precious' files.\n\n - Customized \"diff -p\" markers per path (Johannes, on #git\n 2007-04-30).\n\n I think it makes sense to give an extra parameter to xdiff\n machinery to affect how \"diff -p\" markers are constructed (as\n opposed to teach xdiff machinery to read gitattributes -- the\n code does not have path information at that level). The\n simplest interface would be to pass a regexp and have the\n existing code always look for that regexp backwards. A more\n complex one would involve a callback function, but I do not\n know if that kind of complexity is worth it.\n\n - Others???\n\n* upload-pack support for start fetching from any valid point on\n the history, not just published refs. (Erik W. Biederman\n )\n\n* Give --stdin to git-log, similar to git-rev-list\n\nFrom: \"Marco Costalba\" \nMessage-ID: \n\n* Update the lockfile protocol so that closing and renaming are\n done inside lockfile commit time. Some filesystems do not\n like an open file renamed and then closed. Come up with a\n patch and pass Alex for an Ack.\n\n\nProbably not so important ones\n------------------------------\n\n* daemon --strict-symlink.\n\n* Maybe grok PGP signed text/plain in applymbox as well.\n\n* Mbx (not mbox) support for git-mailsplit.\n\n* git-proxy should be spawned with sh -c 'command' $1 $2.\n\n[jc: should it? -- deciding if it should may not be \"trivial\",\nbut if it turns out to be the right thing to do, the change\nitself is trivial.]\n\n* Maybe a true git-proxy command that reads the first request\n pkt-line, and redirects the request to its real destination.\n\n* test scripts for the relative directory path stuff.\n\n\nThe heavier ones\n----------------\n\n* Use blame machinery to track a single file (not path) in a finer\n grained way.\n\nFrom: Linus Torvalds \nMessage-ID: \n\n[jc: I have a fixed-up one parked in 'pu' and also outlined what\nother things I think are needed in my response:\n\n Message-ID: <7vwt06wqv8.fsf@assigned-by-dhcp.cox.net>\n]\n\n* \"git fetch\" should be able to use foreign SCM import backends\n such as svnimport and cvsimport.\n\n* git-clone fails .git/refs/foo (Yann Dirson )\n <20060610225040.GA7766@nowhere.earth>\n"},{"id":"42373","messageId":"200705170539.11402.andyparkins@gmail.com","threadId":"8181","inReplyTo":"11793556371774-git-send-email-junkio@cox.net","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-17T04:39:10Z","receivedAt":"2007-05-17T04:39:10Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007, May 16, Junio C Hamano wrote:\n\n> (3) git-checkout finds there is .gitmodules file in the\n> tree (and the checked-out working file), which\n> describes these subprojects. It looks at the config\n> and notices that it does not yet know about them\n> (obviously this is true, as this is the first checkout\n> after clone, but I am trying to outline how checkout\n> after a merge should work in the general case).\n>\n> \t It determines where to fetch that subproject from,\n> \t perhaps it uses the default URL described in\n> \t .gitmodules file to, while asking the user for\n> \t confirmation and giving the user a chance to override\n> \t it. And it records something in the config -- now that\n> \t project is known to this repository.\n\nI've been thinking about this .gitmodules thing and have a concern. \nAren't we falling into the svn:externals trap?\n\nThe svn:externals property is analagous to our .gitmodules file. svn \nproperties were basically just version controlled out-of-tree meta data \n(making them annoying to work with - in-tree is better). \n\nsvn \"submodule\" support was done by writing something like\n\n subproject svn://host/blah/blah\n\nIn the svn:externals property attached to the directory that \nthe \"subproject\" directory was in. To translate:\n\n svn propset svn:externals \"subproject svn://blah/blah/blah\" .\n\n git clone git://blah/blah/blah subproject\n git add subproject\n\nThe hole that this sort of thing gets you in to is that the \nsvn:externals property is version controlled. Time passes since you \nadded the external; in that time the URL becomes invalid. No problem, \nyou simply change the svn:externals property. KABOOM. Now any \nhistorical checkout fails because it checks out the svn:externals \nproperty from that checkout and tries to use the wrong URL.\n\nOur in-tree .gitmodules will have the same problem. I recognise that \nyou've mitigated that with some \"confirm with the user, store in the \nconfig\" hand waving; but that is just hiding the problem: the submodule \nURL is not something that should be version controlled; it is an \nall-of-history property; when it changes for revision N it changes for \nrevision N-1, N-2, N-3, etc. Storing it in .gitmodules implies that \nit's value in the past has meaning - it doesn't.\n\nYou mentioned yourself that that problem is not confined to the temporal \naccuracy of .gitmodules, there is spatial accuracy too - there is no \nguarantee that user A wants to use the same submodule URL as user B. \nFast forward to when we've got submodule support; let's say you start \nusing it for git-gui (for example). Somehow (let's leave the \"how\" \ntill later) I've gotten a working git tree with a git-gui checked out. \nI go to my laptop and clone that repository (note: NOT the upstream \nrepository). When git-clone hits the git-gui submodule it should not \ngo looking for the upstream git-gui, I will want it to clone my local \ngit-gui submodule. i.e. in-tree .gitmodules URL for git-gui will be \nwrong.\n\nI hope the above shows that in-tree .gitmodules is wrong; it can only \never be a hint, and in a great number of cases it will be an incorrect \nhint.\n\nI know it's so enticing to store it in-tree; it would be great because \nthe normal repository object transfer mechanism would get the URL of \nthe submodule to the receiver with no changes to current \ninfrastructure. I say: tough luck - we need another mechanism. The \nsubmodule URL is a per-repository setting, not a per-project setting. \nWhen fetching, some out-of-band mechanism for telling the other side \nwhat URL _this_ repository thinks the submodule is at needs to be \nsupplied. I don't know what space there is in the git protocol for \nputting that information, but I suspect that that is where it needs to \ngo.\n\nAs an alternative to that, the supermodule could be given the ability to \nproxy for the submodule during clone. It knows where the submodule is \nstored from it's point of view; is there scope for doing a \nvirtual-server-like system were the supermodule git-daemon just changes \nto the submodule repository (in the case it is local) and thereby gives \nthe downstream git access to the submodule without it even needing a \nURL.\n\n> * Perhaps add 'tree' entries in the index. This may make the\n> current cache-tree extension unnecessary, and I suspect it\n> will simplify various paths that deal with D/F conflicts in\n> the current codebase.\n>\n> I suspect this might need 1.6, as it is a one-way backward\n> incompatible change for the 'index', but 'index' is local so\n> it might not be such a big deal. In the worst case, when the\n> users find \"git checkout\" from 1.5.2 does not work in a\n> repository checked out with such an updated index format, we\n> could ask them to \"rm -f .git/index && git checkout HEAD\".\n\nI don't think even that would be necessary. Assuming that the new index \nformat is a superset of the old index format the only way that tree \nentries would get in the index would be by using git-1.6. Almost by \ndefinition then, if they are in there your git is up-to-date enough to \nuse them. (modulo me not really understanding what you mean)\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"42377","messageId":"7v4pmcauu3.fsf@assigned-by-dhcp.cox.net","threadId":"8181","inReplyTo":"200705170539.11402.andyparkins@gmail.com","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-17T05:21:40Z","receivedAt":"2007-05-17T05:21:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> Our in-tree .gitmodules will have the same problem. I recognise that \n> you've mitigated that with some \"confirm with the user, store in the \n> config\" hand waving; but that is just hiding the problem: the submodule \n> URL is not something that should be version controlled; it is an \n> all-of-history property; when it changes for revision N it changes for \n> revision N-1, N-2, N-3, etc. Storing it in .gitmodules implies that \n> it's value in the past has meaning - it doesn't.\n\nI think that depends _WHY_ the URL recorded .gitmodules are\nupdated. It would perfectly be reasonable for release #1 of an\nappliance project to bind linux 2.4 tree at kernel/ subdirectory\nwhile release #2 source to have 2.6 one; they come from two\ndifferent repository URLs. When you seek the superproject back\nto release #1, you would still want to fetch from 2.4 upstream\nif you are updating.\n\nIf the URL is changed only because the logically same project\nwas relocated to different hosting service, then what you say is\ntrue.\n\nWhat I was \"handwaving\" (or \"envisioning\") was to have something\nlike this in .gitmodules:\n\n\t[subproject \"kernel/\"]\n \tURL = git://git.kernel.org/pub/linux-2.4.git\n\n(or 2.6, depending on the revision of the superproject) and per\nrepository configuration would maps this with these two entries:\n\n\t[subproject \"git://git.kernel.org/pub/linux-2.4.git\"]\n \tURL = http://www.kernel.org/pub/linux-2.4.git\n\n\t[subproject \"git://git.kernel.org/pub/linux-2.6.git\"]\n \tURL = http://www.kernel.org/pub/linux-2.6.git\n\nThe intent is \n\n\t(1) \"kernel/\" directory is found to be a gitlink in the\n tree/index; .gitmodules is consulted to find the\n \"URL\", which is just a handle and the initial hint\n\n\t(2) That \"initial hint\" is used to look up the\n subproject entry from the configuration, to find the\n \"real\" URL that is used by this repository\n\n> You mentioned yourself that that problem is not confined to the temporal \n> accuracy of .gitmodules, there is spatial accuracy too - there is no \n> guarantee that user A wants to use the same submodule URL as user B. \n\nwhich hopefully is already answered by the above handwaving ;-).\n\nThe case of \"relocated to different hosting site\" would also be\nsolved by having more than one entries in the configuration\nfile. If a project that used to be hosted at git.or.cz has\nmigrated to git.sf.net, its .gitmodules file from an earlier\nrevision would have URL pointing at git.repo.cz and newer ones\nwould point at git.sf.net. If you started following that\nproject before the migration, you would have:\n\n\t[subproject \"git://git.or.cz/sub.git\"]\n \tURL = git://git.or.cz/sub.git\n\nin your .git/config. After the repository migrates to\ngit.sf.net, you would update that existing entry and also add\nanother entry, so that .git/config would have these two entries:\n\n\t[subproject \"git://git.or.cz/sub.git\"]\n \tURL = git://git.sf.net/sub.git\n\n\t[subproject \"git://git.sf.net/sub.git\"]\n \tURL = git://git.sf.net/sub.git\n"},{"id":"42381","messageId":"200705170851.26548.andyparkins@gmail.com","threadId":"8181","inReplyTo":"7v4pmcauu3.fsf@assigned-by-dhcp.cox.net","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-17T07:51:25Z","receivedAt":"2007-05-17T07:51:25Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 May 17, Junio C Hamano wrote:\n\n> I think that depends _WHY_ the URL recorded .gitmodules are\n> updated. It would perfectly be reasonable for release #1 of an\n> appliance project to bind linux 2.4 tree at kernel/ subdirectory\n> while release #2 source to have 2.6 one; they come from two\n> different repository URLs. When you seek the superproject back\n> to release #1, you would still want to fetch from 2.4 upstream\n> if you are updating.\n\nThat's a very good point; I hadn't considered that there was a case for \nrecording a change.\n\n> What I was \"handwaving\" (or \"envisioning\") was to have something\n> like this in .gitmodules:\n\nSorry, \"handwaving\" was a bit rude - I certainly didn't mean that you weren't \nsupplying sufficient detail for the circumstance; I meant that in the sense \nof the tricky bits being papered over with user overrides and questions about \nwhich URL to /really/ use. The fact that you even felt it necessary to \nmention those overrides signals, I think, that something is wrong.\n\n> \t[subproject \"kernel/\"]\n> \tURL = git://git.kernel.org/pub/linux-2.4.git\n>\n> (or 2.6, depending on the revision of the superproject) and per\n> repository configuration would maps this with these two entries:\n\nSo now - running with your example - I'm in a project with a 2.6 URL \nin .gitmodules and config; now I check out a past revision. .gitmodules is \nupdated to show the URL at that time (2.4) - what happens to config, which \nmust have higher precedence? Am I meant to update that myself? So, as I hop \naround between branches you expect that I will be updating the config file \nfor each checkout?\n\n> \t[subproject \"git://git.kernel.org/pub/linux-2.4.git\"]\n> \tURL = http://www.kernel.org/pub/linux-2.4.git\n>\n> \t[subproject \"git://git.kernel.org/pub/linux-2.6.git\"]\n> \tURL = http://www.kernel.org/pub/linux-2.6.git\n\nNow this part I love. _That_ is a proper solution. To me though, these are a \ncompletely different category from the [subproject] above. I think that \nshould be highlighted with a different section name like \"[urlmap]\".\n \n> The intent is\n>\n> \t(1) \"kernel/\" directory is found to be a gitlink in the\n> tree/index; .gitmodules is consulted to find the\n> \"URL\", which is just a handle and the initial hint\n\nIn which case that [subproject \"kernel/\"] section is not needed (I think it \nwould be better to simply say \"URL not found for submodule kernel/\" or \nsomething if there is no .gitmodules rather than supplying that override).\n\n> \t(2) That \"initial hint\" is used to look up the\n> subproject entry from the configuration, to find the\n> \"real\" URL that is used by this repository\n\nYes. Excellent; the \"hint\" now becomes a lookup key into the url mappings.\n\n> which hopefully is already answered by the above handwaving ;-).\n\nAbsolutely. I'm very impressed. It solves both the temporal and spatial \nchanges problem because one can remap every URL that was ever used in the \nhistory of the .gitmodules file if one wanted.\n\n> in your .git/config. After the repository migrates to\n> git.sf.net, you would update that existing entry and also add\n> another entry, so that .git/config would have these two entries:\n>\n> \t[subproject \"git://git.or.cz/sub.git\"]\n> \tURL = git://git.sf.net/sub.git\n>\n> \t[subproject \"git://git.sf.net/sub.git\"]\n> \tURL = git://git.sf.net/sub.git\n\nI don't suppose the second one is needed; wouldn't the default be $key = $url, \nwhen no override is found?\n\nThis also raises the point that these mappings would probably be \norder-dependent; because it may be that I want to do:\n\n [subproject \"git://git.or.cz/sub.git\"]\n URL = git://git.sf.net/sub.git\n\n [subproject \"git://git.sf.net/sub.git\"]\n URL = /home/andyp/git/mycopyofsub.git\n\nIn conclusion: I think that's a first class solution to the problem (and \nprobably what you had in mind all along, and me screaming around wasn't \nhelpful :-)).\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"42385","messageId":"20070517110225.GA3334@steel.home","threadId":"8181","inReplyTo":"7v4pmcauu3.fsf@assigned-by-dhcp.cox.net","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-17T11:02:25Z","receivedAt":"2007-05-17T11:02:25Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Thu, May 17, 2007 07:21:40 +0200:\n> What I was \"handwaving\" (or \"envisioning\") was to have something\n> like this in .gitmodules:\n> \n> \t[subproject \"kernel/\"]\n> \tURL = git://git.kernel.org/pub/linux-2.4.git\n\nSo, assuming .gitmodules is versioned (afaics, it is), it would mean\nthat after a some unlucky git-pull, where someone changed the upstream\n.gitmodules (\"linux-2.4\" for whatever reason is changed to just\n\"linux\"). And suddenly all such local configuration is useless:\n\n> (or 2.6, depending on the revision of the superproject) and per\n> repository configuration would maps this with these two entries:\n> \n> \t[subproject \"git://git.kernel.org/pub/linux-2.4.git\"]\n> \tURL = http://www.kernel.org/pub/linux-2.4.git\n>\n> \t[subproject \"git://git.kernel.org/pub/linux-2.6.git\"]\n\nisn't there a typo somewhere around \"2.6\"?\n\n> \tURL = http://www.kernel.org/pub/linux-2.6.git\n\nbecause there is no URL to map from.\n\nwhy can't I just have _repo_ configuration:\n\n \t[subproject \"kernel/\"]\n \tURL = http://www.kernel.org/pub/linux-2.6.git\n?\nIt can be first-time cloned from the upstream, but it stays after\npeople change it to suit their systems. They can depend on it not to\nbe broken by upstream.\n\n> The intent is \n> \n> \t(1) \"kernel/\" directory is found to be a gitlink in the\n> tree/index; .gitmodules is consulted to find the\n> \"URL\", which is just a handle and the initial hint\n> \n> \t(2) That \"initial hint\" is used to look up the\n> subproject entry from the configuration, to find the\n> \"real\" URL that is used by this repository\n\nIt is quite long-living to be just initial hint. And will be redundant\nafter the hint loses all meaning (after some time it _will_ happen,\nsites do move around), and is just a strange looking mapping key.\n\nCan I suggest a part of repo configuration to be clonable? So that\nthere is a something in .git/config.dist, which is _cloned_ with\ngit-clone. The obviuos thing to put there would be subproject\nconfiguration, and maybe there will be something else in the future\n(I'd think of description, which is a separate file now, and as for\nnow, the only way to get this description is to use gitweb or ssh).\ngit-ls-remote could be made to show this \"remote-accessible\"\nconfiguration, in case someone have to update/compare local copy of\nthis config.\n"},{"id":"42392","messageId":"20070517124622.GP4489@pasky.or.cz","threadId":"8181","inReplyTo":"20070517110225.GA3334@steel.home","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-17T12:46:22Z","receivedAt":"2007-05-17T12:46:22Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, May 17, 2007 at 01:02:25PM CEST, Alex Riesen wrote:\n> why can't I just have _repo_ configuration:\n> \n> \t[subproject \"kernel/\"]\n> \tURL = http://www.kernel.org/pub/linux-2.6.git\n> ?\n> It can be first-time cloned from the upstream, but it stays after\n> people change it to suit their systems. They can depend on it not to\n> be broken by upstream.\n\nBecause kernel/ can get removed, moved around, or point at entirely\n*different* projects over time and branches - kernel/ can switch from\nlinux-2.4 to linux-2.6, libc/ can switch between glibc and uClibc, ...\n\n> Can I suggest a part of repo configuration to be clonable? So that\n> there is a something in .git/config.dist, which is _cloned_ with\n> git-clone. The obviuos thing to put there would be subproject\n> configuration, and maybe there will be something else in the future\n> (I'd think of description, which is a separate file now, and as for\n> now, the only way to get this description is to use gitweb or ssh).\n> git-ls-remote could be made to show this \"remote-accessible\"\n> configuration, in case someone have to update/compare local copy of\n> this config.\n\nThis is troublesome because then you will also need a way to update the\nconfiguration in the future, otherwise you will run into some\nembarassing situations, and since we don't even support any motds while\nfetching, when something *needs* to be changed you don't even have a\ngood way to tell your users. (Actually, I've been thinking about adding\nmotd support to the fetchers. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"42395","messageId":"alpine.LFD.0.99.0705170941590.24220@xanadu.home","threadId":"8181","inReplyTo":"7v4pmcauu3.fsf@assigned-by-dhcp.cox.net","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-05-17T13:45:24Z","receivedAt":"2007-05-17T13:45:24Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 16 May 2007, Junio C Hamano wrote:\n\n> Andy Parkins writes:\n> \n> > Our in-tree .gitmodules will have the same problem. I recognise that \n> > you've mitigated that with some \"confirm with the user, store in the \n> > config\" hand waving; but that is just hiding the problem: the submodule \n> > URL is not something that should be version controlled; it is an \n> > all-of-history property; when it changes for revision N it changes for \n> > revision N-1, N-2, N-3, etc. Storing it in .gitmodules implies that \n> > it's value in the past has meaning - it doesn't.\n> \n> I think that depends _WHY_ the URL recorded .gitmodules are\n> updated. It would perfectly be reasonable for release #1 of an\n> appliance project to bind linux 2.4 tree at kernel/ subdirectory\n> while release #2 source to have 2.6 one; they come from two\n> different repository URLs. When you seek the superproject back\n> to release #1, you would still want to fetch from 2.4 upstream\n> if you are updating.\n\nI don't know if the above example should make sense. In practice that \nwould mean you'll have to _replace_ the repo within the submodule \ndirectory which is quite different from merely checking out a different \nversion of the same repository.\n\n\nNicolas\n"},{"id":"42396","messageId":"20070517134649.GA20853@coredump.intra.peff.net","threadId":"8181","inReplyTo":"20070517124622.GP4489@pasky.or.cz","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-17T13:46:49Z","receivedAt":"2007-05-17T13:46:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 17, 2007 at 02:46:22PM +0200, Petr Baudis wrote:\n\n> > why can't I just have _repo_ configuration:\n> > \n> > \t[subproject \"kernel/\"]\n> > \tURL = http://www.kernel.org/pub/linux-2.6.git\n> > ?\n> > It can be first-time cloned from the upstream, but it stays after\n> > people change it to suit their systems. They can depend on it not to\n> > be broken by upstream.\n> \n> Because kernel/ can get removed, moved around, or point at entirely\n> *different* projects over time and branches - kernel/ can switch from\n> linux-2.4 to linux-2.6, libc/ can switch between glibc and uClibc, ...\n\nI think we clearly need a 2-level system: a tracked pointer to the repo,\nwith an optional local override.\n\nHowever, I don't quite like Junio's idea of using the URL as a key,\nsince it is intended to change. IOW, if I am overriding your URL via\n.git/config, if you change your URL then my config is now broken.\n\nInstead, why not:\n 1. url location is supplied in configuration as\n [subproject \"kernel/\"]\n url = git://git.kernel.org/pub/linux-2.4.git\n 2. .gitmodules is simply read as a lower-priority version of\n configuration\n\nOne advantage of this approach is that it's totally general; instead of\n.gitmodules, we could in fact be talking about .gitconfig, a mechanism\nfor projects to contain tracked configuration that can be overridden by\nindividual repos. For some projects, I imagine some of the commit\nencoding config options might make sense.\n\nThoughts?\n\n-Peff\n"},{"id":"42410","messageId":"20070517161002.GR4489@pasky.or.cz","threadId":"8181","inReplyTo":"20070517134649.GA20853@coredump.intra.peff.net","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-17T16:10:02Z","receivedAt":"2007-05-17T16:10:02Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, May 17, 2007 at 03:46:49PM CEST, Jeff King wrote:\n> On Thu, May 17, 2007 at 02:46:22PM +0200, Petr Baudis wrote:\n> \n> > > why can't I just have _repo_ configuration:\n> > > \n> > > \t[subproject \"kernel/\"]\n> > > \tURL = http://www.kernel.org/pub/linux-2.6.git\n> > > ?\n> > > It can be first-time cloned from the upstream, but it stays after\n> > > people change it to suit their systems. They can depend on it not to\n> > > be broken by upstream.\n> > \n> > Because kernel/ can get removed, moved around, or point at entirely\n> > *different* projects over time and branches - kernel/ can switch from\n> > linux-2.4 to linux-2.6, libc/ can switch between glibc and uClibc, ...\n> \n> I think we clearly need a 2-level system: a tracked pointer to the repo,\n> with an optional local override.\n> \n> However, I don't quite like Junio's idea of using the URL as a key,\n> since it is intended to change. IOW, if I am overriding your URL via\n> .git/config, if you change your URL then my config is now broken.\n> \n> Instead, why not:\n> 1. url location is supplied in configuration as\n> [subproject \"kernel/\"]\n> url = git://git.kernel.org/pub/linux-2.4.git\n> 2. .gitmodules is simply read as a lower-priority version of\n> configuration\n\nBut, did you read what you actually quoted? Because I can only repeat my\nargument in the face of (1), and you didn't seem to dispute any part of\nit at all.\n\n\"kernel/\" has _no_ meaning. Only a (treeid,\"kernel/\") pair has meaning,\nnothing less - a particular tree contains a submodule in given subtree.\nDifferent trees can have different submodules in different subtrees.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"42411","messageId":"20070517162542.GA28501@coredump.intra.peff.net","threadId":"8181","inReplyTo":"20070517161002.GR4489@pasky.or.cz","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-17T16:25:42Z","receivedAt":"2007-05-17T16:25:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 17, 2007 at 06:10:02PM +0200, Petr Baudis wrote:\n\n> But, did you read what you actually quoted? Because I can only repeat my\n> argument in the face of (1), and you didn't seem to dispute any part of\n> it at all.\n\nYou said:\n> Because kernel/ can get removed, moved around, or point at entirely\n> *different* projects over time and branches - kernel/ can switch from\n> linux-2.4 to linux-2.6, libc/ can switch between glibc and uClibc, ...\n\nwhich I took to mean that we must be able to track changes to the URL\nwhich is pointed to by the kernel/ submodule, and therefore this\nconfiguration must be in a tracked file. Which is _precisely_ what I\nadvocated: it goes in a .gitmodules (or .gitconfig) file in the tracked\ndirectory. This is counter to what Alex says, which is that one should\nsimply pull the config down during clone time and never change it.\n\nHowever, I think we _must_ have an override mechanism, since I don't\nnecessarily use the same URLs that you do. I propose that such overrides\nshould go into the local repo config. The only difference between what I\nhave proposed and what Junio mentioned is that I would base the config\noverride key on the directory name, not the URL. This means that if\nupstream changes their pointer to the URL, yours will change with it\n_unless you have an override_. With Junio's, their change of URL will\noverride your change (since the key will no longer match your config).\n\nHow do you propose to handle overrides?\n\n> \"kernel/\" has _no_ meaning. Only a (treeid,\"kernel/\") pair has meaning,\n> nothing less - a particular tree contains a submodule in given subtree.\n> Different trees can have different submodules in different subtrees.\n\nRight. In my proposal (unlike Alex's), it _is_ tied to the tree, since\nthat tree has a particular .gitmodules. But I also think you should be\nable to override the submodule URL for kernel/ _for all time_ if you\nwant.\n\n-Peff\n"},{"id":"42419","messageId":"20070517173005.GS4489@pasky.or.cz","threadId":"8181","inReplyTo":"20070517162542.GA28501@coredump.intra.peff.net","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-17T17:30:05Z","receivedAt":"2007-05-17T17:30:05Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, May 17, 2007 at 06:25:42PM CEST, Jeff King wrote:\n> However, I think we _must_ have an override mechanism, since I don't\n> necessarily use the same URLs that you do. I propose that such overrides\n> should go into the local repo config. The only difference between what I\n> have proposed and what Junio mentioned is that I would base the config\n> override key on the directory name, not the URL. This means that if\n> upstream changes their pointer to the URL, yours will change with it\n> _unless you have an override_. With Junio's, their change of URL will\n> override your change (since the key will no longer match your config).\n> \n> How do you propose to handle overrides?\n\nI think Junio's URL keying works fine. Their change of URL will override\nyour change, but that is bad thing only when the old upstream's URL\nchanged, but the upstream stays the same. Then either the problem is\nclearly visible or it will result only in somewhat suboptimal behaviour.\n\nOTOH, if the _upstream_ changed and your override scheme is at work, you\nwon't notice at all and simply will continue to use the same old\nupstream.\n\n> > \"kernel/\" has _no_ meaning. Only a (treeid,\"kernel/\") pair has meaning,\n> > nothing less - a particular tree contains a submodule in given subtree.\n> > Different trees can have different submodules in different subtrees.\n> \n> Right. In my proposal (unlike Alex's), it _is_ tied to the tree, since\n> that tree has a particular .gitmodules. But I also think you should be\n> able to override the submodule URL for kernel/ _for all time_ if you\n> want.\n\nBut again - \"kernel/\" means nothing, only \"kernel/ in tree X\". kernel/\nmight point to linux-2.4 in older trees, linux-2.6 in newer trees, -mm\nin the experimental branch and freebsd tree in the weirdo branch. Such\nan override is _never_ going to work in the general situation, only when\n\"kernel/\" always in all commits on all branches points to the same\nsingle project. (You can work that around by at least making the setting\nbranch-specific, but that still doens't take into account the history,\nand then newly created branches won't have the override you want, etc.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"42420","messageId":"20070517173534.GA29607@coredump.intra.peff.net","threadId":"8181","inReplyTo":"20070517173005.GS4489@pasky.or.cz","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-17T17:35:34Z","receivedAt":"2007-05-17T17:35:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 17, 2007 at 07:30:05PM +0200, Petr Baudis wrote:\n\n> I think Junio's URL keying works fine. Their change of URL will override\n> your change, but that is bad thing only when the old upstream's URL\n> changed, but the upstream stays the same. Then either the problem is\n> clearly visible or it will result only in somewhat suboptimal behaviour.\n> \n> OTOH, if the _upstream_ changed and your override scheme is at work, you\n> won't notice at all and simply will continue to use the same old\n> upstream.\n\nRight. But I think it makes more sense for the error condition to go the\nother way (that is, your override might get stale, but it will always be\nan _override_). You'll notice eventually anyway when upstream moves to a\ncommit sha1 that you don't have in your submodule repo (or if they never\ndo, that means your override tree actually _is_ valid, and didn't need\nto be changed anyway; this would be the case if upstream moved to a\ndifferent mirror, but you were already using an alternate source\nanyway).\n\n> But again - \"kernel/\" means nothing, only \"kernel/ in tree X\". kernel/\n> might point to linux-2.4 in older trees, linux-2.6 in newer trees, -mm\n> in the experimental branch and freebsd tree in the weirdo branch. Such\n> an override is _never_ going to work in the general situation, only when\n> \"kernel/\" always in all commits on all branches points to the same\n> single project. (You can work that around by at least making the setting\n> branch-specific, but that still doens't take into account the history,\n> and then newly created branches won't have the override you want, etc.)\n\nMy point is that we _already_ have a mechanism that unambiguously points\nto the linked commit, and it's _not_ the URL; it's the commit sha1\nembedded in the tree. Everything else is just a hint about where we\nmight find that commit.\n\n-Peff\n"},{"id":"42423","messageId":"7v4pmb9tip.fsf@assigned-by-dhcp.cox.net","threadId":"8181","inReplyTo":"20070517110225.GA3334@steel.home","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-17T18:47:42Z","receivedAt":"2007-05-17T18:47:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> Junio C Hamano, Thu, May 17, 2007 07:21:40 +0200:\n>> What I was \"handwaving\" (or \"envisioning\") was to have something\n>> like this in .gitmodules:\n>> \n>> \t[subproject \"kernel/\"]\n>> \tURL = git://git.kernel.org/pub/linux-2.4.git\n>\n> So, assuming .gitmodules is versioned (afaics, it is), it would mean\n> that after a some unlucky git-pull, where someone changed the upstream\n> .gitmodules (\"linux-2.4\" for whatever reason is changed to just\n> \"linux\"). And suddenly all such local configuration is useless:\n\nSee below.\n\n>> (or 2.6, depending on the revision of the superproject) and per\n>> repository configuration would maps this with these two entries:\n>> \n>> \t[subproject \"git://git.kernel.org/pub/linux-2.4.git\"]\n>> \tURL = http://www.kernel.org/pub/linux-2.4.git\n>>\n>> \t[subproject \"git://git.kernel.org/pub/linux-2.6.git\"]\n>\n> isn't there a typo somewhere around \"2.6\"?\n>\n>> \tURL = http://www.kernel.org/pub/linux-2.6.git\n>\n> because there is no URL to map from.\n\nThe basic idea is that you keep mappings for all the URLs that\nappear in versions of .gitmodules in the history you are\ninterested in checking out. If the upstream switches from 2.4\nbased one to 2.6 based one, .gitmodules would contain a new URL,\nwhich is not yet known to your configuration. Then either the\nUI would ask, with the default hint in the .gitmodules you just\npulled, refuse and have you manually add it to your config after\nconfirming, or just take the default (iow \"trust the upstream\").\n\nSo, no, it is not a reason to drop older mappings when your tip\nwas updated by a pull. It should still be possible to checkout\nolder version that depend on the older 2.4 based subproject.\n\n> why can't I just have _repo_ configuration:\n>\n> \t[subproject \"kernel/\"]\n> \tURL = http://www.kernel.org/pub/linux-2.6.git\n> ?\n> It can be first-time cloned from the upstream, but it stays after\n> people change it to suit their systems. They can depend on it not to\n> be broken by upstream.\n\nBut that is a wrong thing to do when you are forking from the\nrelease #1 of the appliance project, which wanted to have 2.4\nbased on at that path.\n"},{"id":"42424","messageId":"7vzm438evr.fsf@assigned-by-dhcp.cox.net","threadId":"8181","inReplyTo":"20070517134649.GA20853@coredump.intra.peff.net","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-17T18:49:12Z","receivedAt":"2007-05-17T18:49:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Instead, why not:\n> 1. url location is supplied in configuration as\n> [subproject \"kernel/\"]\n> url = git://git.kernel.org/pub/linux-2.4.git\n> 2. .gitmodules is simply read as a lower-priority version of\n> configuration\n\nThat does not support seeking back and forth between appliance\nrelease #1 and release #2 which wants to say they want to bind\ntwo different things at the same kernel/ path, does it?\n"},{"id":"42435","messageId":"20070517215841.GB29259@mellanox.co.il","threadId":"8181","inReplyTo":"7v4pmcauu3.fsf@assigned-by-dhcp.cox.net","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-05-17T21:58:41Z","receivedAt":"2007-05-17T21:58:41Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> What I was \"handwaving\" (or \"envisioning\") was to have something\n> like this in .gitmodules:\n> \n> \t[subproject \"kernel/\"]\n> \tURL = git://git.kernel.org/pub/linux-2.4.git\n> \n> (or 2.6, depending on the revision of the superproject) and per\n> repository configuration would maps this with these two entries:\n> \n> \t[subproject \"git://git.kernel.org/pub/linux-2.4.git\"]\n> \tURL = http://www.kernel.org/pub/linux-2.4.git\n> \n> \t[subproject \"git://git.kernel.org/pub/linux-2.6.git\"]\n> \tURL = http://www.kernel.org/pub/linux-2.6.git\n> \n> The intent is \n> \n> \t(1) \"kernel/\" directory is found to be a gitlink in the\n> tree/index; .gitmodules is consulted to find the\n> \"URL\", which is just a handle and the initial hint\n> \n> \t(2) That \"initial hint\" is used to look up the\n> subproject entry from the configuration, to find the\n> \"real\" URL that is used by this repository\n\nI'm reading up on submodules, two questions on this:\n\n1. I understand the usefulness of the hint for public repositories, (the user might\nneed help discovering where to get submodules) but for private ones would this\ncreate a hassle: I start with a subproject in ~/subprojecttest and if that gets\nput in the URL hint, I have to maintain a map for ~/subprojecttest in my\n.git/config forever even after I move it to ~/subprojectproduction, just to make\nold releases build?\nDo you think it might make sense to support a mode where .gitmodules\nis empty, and URLs come from the config directly?\n\n2. Suppose .gitmodules in upstream tree points at subproject repo at kernel.org,\nand I clone from there - my repo will point at kernel.org by default?\nBut now, I'd like everyone who clones from *my* repo to get\npointed at *my* server by default (e.g. for mirroring),\nbut would not changing .gitmodules create a commit so my\nhead will now differ from upstream - so it won't be signed properly etc...\nDid I misunderstand something?\n\n-- \nMST\n"},{"id":"42440","messageId":"200705180141.06862.Josef.Weidendorfer@gmx.de","threadId":"8181","inReplyTo":"20070517215841.GB29259@mellanox.co.il","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-05-17T23:41:06Z","receivedAt":"2007-05-17T23:41:06Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Thursday 17 May 2007, Michael S. Tsirkin wrote:\n> > What I was \"handwaving\" (or \"envisioning\") was to have something\n> > like this in .gitmodules:\n> > \n> > \t[subproject \"kernel/\"]\n> > \tURL = git://git.kernel.org/pub/linux-2.4.git\n> > \n> > (or 2.6, depending on the revision of the superproject) and per\n> > repository configuration would maps this with these two entries:\n> > \n> > \t[subproject \"git://git.kernel.org/pub/linux-2.4.git\"]\n> > \tURL = http://www.kernel.org/pub/linux-2.4.git\n> > \n> > \t[subproject \"git://git.kernel.org/pub/linux-2.6.git\"]\n> > \tURL = http://www.kernel.org/pub/linux-2.6.git\n> > \n> > The intent is \n> > \n> > \t(1) \"kernel/\" directory is found to be a gitlink in the\n> > tree/index; .gitmodules is consulted to find the\n> > \"URL\", which is just a handle and the initial hint\n> > \n> > \t(2) That \"initial hint\" is used to look up the\n> > subproject entry from the configuration, to find the\n> > \"real\" URL that is used by this repository\n> \n> I'm reading up on submodules, two questions on this:\n> \n> 1. I understand the usefulness of the hint for public repositories, (the user might\n> need help discovering where to get submodules) but for private ones would this\n> create a hassle: I start with a subproject in ~/subprojecttest and if that gets\n> put in the URL hint, I have to maintain a map for ~/subprojecttest in my\n> .git/config forever even after I move it to ~/subprojectproduction, just to make\n> old releases build?\n\nYes, AFAICS that was the original idea; but that is no problem as we will need an\noverride scheme.\n\nHowever, I think the usage of \"url\"/\"url hint\" as the 1st level subproject identifier\nreally is badly misleading and confusing for users; it would be better for this\nidentifier to not look like a URL at all. But by naming it \"url\" in .gitmodules, the\nuser is tempted to put an URL at this place.\n\nIMHO it is by far better to simply talk about the \"subproject name/identifier\" which is\nvalid in the subproject namespace of the superproject.\n\nAnd why not use the .gitattributes for the \".gitmodules\" needs? \nWith linux 2.4 as subproject in \"top/kernel/\", there could be a \"top/.gitattributes\"\nwith \n\n kernel subproject=linux24\n\nWe could have a default rule that in the absense of the attribute, we default to the\npath of the submodule, ie. to\n\n kernel subproject=top/kernel\n\nIn .git/config, there needs to be a config entry like\n\n\t[subproject \"linux24\"]\n\t\tURL = http://www.kernel.org/pub/linux-2.4.git\n\nAgain, we could have a default URL in the absence of this config entry which is\nrelative to the URL of the superproject, and which allows for the superproject\nrepository to act as proxy.\n\nAs relative path I would propose $SUPERURL/subproject/$SUBPROJECTNAME, ie. if\nthe superproject is at git://git.kernel.org/pub/super.git, the above subproject\nwould default to the URL git://git.kernel.org/pub/super.git/subproject/linux24\nwhich could be a symlink on the server.\n\nTo support different subproject repositories linked in at the\nsame path of a superproject, Nicolas noted that we would have to replace\nthe subproject repository at top/kernel/.git (taking my example above)\nwhenever we cross the subproject change boundary in a checkout (e.g. from\nlinux24 to linux26). The natural thing here would be to have\nsubproject repositories at a seperate place, like inside of the superproject\nrepository such as at \".git/subproject/linux24\", which works well with my\ndefault interpretation of relative subproject paths above. At checkout,\nthe correct repository would be bound by a symlink:\n\n top/kernel/.git -> .git/subproject/linux24\n\nInstead of a symlink, a magically working linkage mechanisms would be better\n(the .git/gitlink proposal).\n\n> 2. Suppose .gitmodules in upstream tree points at subproject repo at kernel.org,\n> and I clone from there - my repo will point at kernel.org by default?\n> But now, I'd like everyone who clones from *my* repo to get\n> pointed at *my* server by default (e.g. for mirroring),\n> but would not changing .gitmodules create a commit so my\n> head will now differ from upstream - so it won't be signed properly etc...\n> Did I misunderstand something?\n\nNo, that is correct. Supporting a relative URL specification as proposed above\nshould solve this issue.\n\nJosef\n\n> \n"},{"id":"42442","messageId":"464CF435.1010405@midwinter.com","threadId":"8181","inReplyTo":"200705180141.06862.Josef.Weidendorfer@gmx.de","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-05-18T00:32:53Z","receivedAt":"2007-05-18T00:32:53Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"It seems like a lot of the friction here is because people are trying to \ndevise a single mechanism that will handle two distinct cases:\n\n1. The location of a subproject's changed (the \"public repository \nrelocated to a different host\" problem). This is not temporally \nsensitive -- if you check out an old version of the superproject, you \nneed to look in the new location for the subproject. A local override \nfor the subproject's location will likely still be perfectly valid.\n\n2. The superproject no longer wants to use the same subproject; it wants \nto replace it with something else at the same point in the tree (the \n\"version 2 of superproject uses the 2.6 kernel as opposed to the 2.4 \nkernel\"). This is temporally sensitive -- if you check out an old \nversion of the superproject, you want to use the old location for the \nsubproject too. A single local override will most likely not be valid \nfor both versions.\n\nI think these are fundamentally different operations and it's the desire \nto fold them into one mechanism that's leading to a lot of the \ndiscussion here. Would we simplify things by not conflating them?\n\nFor example -- and yes, this is partially a rehash of other people's \nideas -- instead of mapping a subproject path directly to revision@URL, \ninstead map it to revision@symbolic name. The symbolic name is then \nseparately mapped to a URL, and it's that symbolic name that can be \nlocally overridden. The mappings of symbolic names to URLs is \nunversioned; the mapping of subprojects to revision@symbolic is \nversioned. Local overrides happen at the symbolic->URL mapping.\n\nSo you'd have something like\n\nversion 1: kernel-src/ -> kernel24\nversion 2: kernel-src/ -> kernel26\nunversioned:\n kernel24 -> git://whatever/2.4\n kernel26 -> git://whatever/2.6\n\nAnd then locally, the override is:\n\n kernel24 -> git://myhost/2.4\n\nWhen version 2 gets pulled down, you start off using the upstream's URL, \nwhich you know because you pulled down the new copy of the unversioned \nsymbolic->URL map. Maybe git-pull gives you a warning like, \"I see you \nhave some overrides, so you might want to know about this new symbolic \nname too.\" With an appropriate option it might even stop before doing \nanything with the new symbolic name to give you a chance to override.\n\nMaybe that has some problems I'm not seeing, but it seems like adding \none more layer of indirection which has different versioning semantics \nwould make this a more tractable problem.\n\n-Steve\n"},{"id":"42445","messageId":"20070518045025.GT4489@pasky.or.cz","threadId":"8181","inReplyTo":"464CF435.1010405@midwinter.com","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-18T04:50:25Z","receivedAt":"2007-05-18T04:50:25Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, May 18, 2007 at 02:32:53AM CEST, Steven Grimm wrote:\n> For example -- and yes, this is partially a rehash of other people's \n> ideas -- instead of mapping a subproject path directly to revision@URL, \n> instead map it to revision@symbolic name. The symbolic name is then \n> separately mapped to a URL, and it's that symbolic name that can be \n> locally overridden. The mappings of symbolic names to URLs is \n> unversioned; the mapping of subprojects to revision@symbolic is \n> versioned. Local overrides happen at the symbolic->URL mapping.\n> \n> So you'd have something like\n> \n> version 1: kernel-src/ -> kernel24\n> version 2: kernel-src/ -> kernel26\n> unversioned:\n> kernel24 -> git://whatever/2.4\n> kernel26 -> git://whatever/2.6\n> \n> And then locally, the override is:\n> \n> kernel24 -> git://myhost/2.4\n\nYes, this would be nice; in one of my first mails in this thread I\ndevoted a non-trivially large writeup to this, then proceeded to remove\nit since this has a serious problem.\n\nActually, Git already has a nice mechanism to handle these unversionaed\npointers - tags. Just make refs/tags/subproject/kernel24 containing the\nURL to fetch. It's even easily overridable locally (and not easily\noverridable remotely...).\n\nThe problem is ugly too, though - suddenly, you have created a SINGLE\nUNIVERSE-WIDE NAMESPACE INSIDE A DISTRIBUTED VCS. And that's not going\nto work well. I think I don't have to elaborate too much - the\naforementioned FreeBSD people will have different ideas about kernels\nthan you, _you_ will have different idea about kernels in few tens of\nyears than now, then if you need to merge or probably even fetch, you\nwill get into big trouble.\n\nNotice that we don't have any such namespace right now (except the\nD(SHA1) namespace, which is however possible only because it's so huge\n_and_ the names are assigned automagically in a way that virtually\nguarantees uniqueness across the whole universe) - tags come closest,\nbut there is nothing that fundamentally breaks when a clash happens\ninside the namespace - it's just UI thing. But subproject names are\netched to the history - once you name it, you just can't get rid of it\nforever.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"42451","messageId":"200705180857.18182.andyparkins@gmail.com","threadId":"8181","inReplyTo":"200705180141.06862.Josef.Weidendorfer@gmx.de","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-18T07:57:16Z","receivedAt":"2007-05-18T07:57:16Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 May 18, Josef Weidendorfer wrote:\n\n> However, I think the usage of \"url\"/\"url hint\" as the 1st level subproject\n> identifier really is badly misleading and confusing for users; it would be\n> better for this identifier to not look like a URL at all. But by naming it\n> \"url\" in .gitmodules, the user is tempted to put an URL at this place.\n\nBear in mind that what you're suggesting is no different in implementation \nfrom what Junio is suggesting but with one difference: in Junio's option \nthe \"identifier\" will act as a default URL if no override is found.\n\nYours:\n\n.gitmodules:\n kernel mykernelsubprojectid\n.git/config\n [subproject \"mykernelsubprojectid\"]\n url = git://host/blah/blah.git\n\nJunio's:\n\n.gitmodules:\n kernel git://oldhost/blah/blah.git\n.git/config\n [subproject \"git://oldhost/blah/blah.git\"]\n url = git://host/blah/blah.git\n\nThere is no difference between these two in terms of implementation. Both \nassign a key to the \"kernel\" submodule then use that key to look up an \noverride. The advantage of Junio's suggestion is that when an override is \nnot needed the key itself is used and therefore it Just Works (tm) with no \nchange to the .git/config necessary.\n\n> And why not use the .gitattributes for the \".gitmodules\" needs?\n\nI can't think of a reason why not; I think that's a separate question though.\n\n> Again, we could have a default URL in the absence of this config entry\n> which is relative to the URL of the superproject, and which allows for the\n> superproject repository to act as proxy.\n\nThis is why Junio's option of URL=Key is better. You are relying on the \ndefault being correct in order for a simple clone to work. The relative path \nscheme you propose as a default, while logical, doesn't match anything that \nanyone does right now. Look at any server that hosts multiple projects; they \nare stored flat not deep:\n\n project1/\n project2/\n project3/\n\nOne advantage of submodule support is that multiple supermodules can contain \nthe same submodule, so you really can't force a hierarchical representation \non the world just to make the default URL correct.\n\n project2/\n project1/\n project3/\n project1/\n\nOops.\n\n> As relative path I would propose $SUPERURL/subproject/$SUBPROJECTNAME, ie.\n> if the superproject is at git://git.kernel.org/pub/super.git, the above\n> subproject would default to the URL\n> git://git.kernel.org/pub/super.git/subproject/linux24 which could be a\n> symlink on the server.\n\nI'm really uncomfortable with the idea of relying on directory structure \npassed the root repository path; from the\n git://git.kernel.org/pub/super.git/\npoint onwards; we don't have any right to expect that this is a real directory \ntree. As an example; svn URLs don't match up with what's on disk:\n\n svn://svnhost/pub/repo/trunk/src\n ^^^^^^^^^^\n\nOn disk there is no such directory as /trunk/src under the repository \ndirectory. In the same way, even technically what you suggest would work, \nthe part of the URL under git://git.kernel.org/pub/super.git/ is git's own \nnamespace - it's not the users to mess with. E.g. if I had a subproject \ncalled \"refs\" you'd be in trouble.\n\n> To support different subproject repositories linked in at the\n> same path of a superproject, Nicolas noted that we would have to replace\n> the subproject repository at top/kernel/.git (taking my example above)\n> whenever we cross the subproject change boundary in a checkout (e.g. from\n> linux24 to linux26). The natural thing here would be to have\n> subproject repositories at a seperate place, like inside of the\n> superproject repository such as at \".git/subproject/linux24\", which works\n> well with my default interpretation of relative subproject paths above. At\n> checkout, the correct repository would be bound by a symlink:\n\nYour objection to the url=key scheme was lack of simplicity - to me the above \nis significantly more complex and is relying far too much on the submodule \nbeing on the same server as the supermodule. Big mistake. A typical use of \nsubmodules would be to integrate someone else's project, not your own, nor \nindeed your own checkout of that project. Why should I have to keep my own \ncopies of, say, kernel2.4 and kernel2.6 when there are perfectly acceptable \nURLs to the real repositories?\n\n> > 2. Suppose .gitmodules in upstream tree points at subproject repo at\n> > kernel.org, and I clone from there - my repo will point at kernel.org by\n> > default? But now, I'd like everyone who clones from *my* repo to get\n> > pointed at *my* server by default (e.g. for mirroring),\n> > but would not changing .gitmodules create a commit so my\n> > head will now differ from upstream - so it won't be signed properly\n> > etc... Did I misunderstand something?\n>\n> No, that is correct. Supporting a relative URL specification as proposed\n> above should solve this issue.\n\nI think that's the wrong solution. A change of source URL for a submodule \nfrom what upstream uses to your own server is a _fork_ from upstream, \ntherefore you would fork your own branch in your supermodule and \nalter .gitmodules to point at your server. Everybody is happy, and the fork \nis recorded.\n\nThe override system is only there for the local repository (which always takes \nprecedence) not for the server provider to hide detail from those checking \nthe repo out.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"42454","messageId":"200705181043.09203.Josef.Weidendorfer@gmx.de","threadId":"8181","inReplyTo":"200705180857.18182.andyparkins@gmail.com","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-05-18T08:43:08Z","receivedAt":"2007-05-18T08:43:08Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 18 May 2007, Andy Parkins wrote:\n> Bear in mind that what you're suggesting is no different in implementation \n> >from what Junio is suggesting but with one difference: in Junio's option \n> the \"identifier\" will act as a default URL if no override is found.\n\nYes; actually, its exactly the same aside from the name used in .gitmodules\nfor it, as I proposed a default URL which is derived from the suproject identifier\nif no config entry is found.\n\n> > Again, we could have a default URL in the absence of this config entry\n> > which is relative to the URL of the superproject, and which allows for the\n> > superproject repository to act as proxy.\n> \n> This is why Junio's option of URL=Key is better.\n\nIt all depends on how we construct the default URL out of the subproject\nidentifier. Options:\n(1) do not try to construct a default URL at all. Error out without a config\n(2) use a configurable rewriting scheme like s/(.*)/git://host/\\1/\n(3) automatically detect a senseful rewriting scheme\n\nLet's start with (1). We can invent convenient default schemes later on.\n\n\nJosef\n"},{"id":"42457","messageId":"20070518085708.GC4708@mellanox.co.il","threadId":"8181","inReplyTo":"200705180857.18182.andyparkins@gmail.com","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-05-18T08:57:08Z","receivedAt":"2007-05-18T08:57:08Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"...\n\n> > As relative path I would propose $SUPERURL/subproject/$SUBPROJECTNAME, ie.\n> > if the superproject is at git://git.kernel.org/pub/super.git, the above\n> > subproject would default to the URL\n> > git://git.kernel.org/pub/super.git/subproject/linux24 which could be a\n> > symlink on the server.\n> \n> I'm really uncomfortable with the idea of relying on directory structure \n> passed the root repository path; from the\n> git://git.kernel.org/pub/super.git/\n> point onwards; we don't have any right to expect that this is a real directory \n> tree. As an example; svn URLs don't match up with what's on disk:\n> \n> svn://svnhost/pub/repo/trunk/src\n> ^^^^^^^^^^\n> \n> On disk there is no such directory as /trunk/src under the repository \n> directory. In the same way, even technically what you suggest would work, \n> the part of the URL under git://git.kernel.org/pub/super.git/ is git's own \n> namespace - it's not the users to mess with. E.g. if I had a subproject \n> called \"refs\" you'd be in trouble.\n\nOh, that's easily solvable: just stick a 'subprojects' directory in there.\nThat is, the default URL to find a subproject would be:\n\n1. For non-bare repo foo/.git/, subproject bar will live in foo/bar/.git\n or foo/bar.git.\n2. For a bare repo foo.git/, subproject bar will live in\n foo.git/subprojects/bar.git.\n\n> > > 2. Suppose .gitmodules in upstream tree points at subproject repo at\n> > > kernel.org, and I clone from there - my repo will point at kernel.org by\n> > > default? But now, I'd like everyone who clones from *my* repo to get\n> > > pointed at *my* server by default (e.g. for mirroring),\n> > > but would not changing .gitmodules create a commit so my\n> > > head will now differ from upstream - so it won't be signed properly\n> > > etc... Did I misunderstand something?\n> >\n> > No, that is correct. Supporting a relative URL specification as proposed\n> > above should solve this issue.\n> \n> I think that's the wrong solution. A change of source URL for a submodule \n> from what upstream uses to your own server is a _fork_ from upstream, \n> therefore you would fork your own branch in your supermodule and \n> alter .gitmodules to point at your server. Everybody is happy, and the fork \n> is recorded.\n\nWhy should I record it? If the content is the same, the commit name should\nbe the same, it shouldn't matter where did the content came from.\n\nI wouldn't be happy: I have just cloned both project and superproject,\nbut to re-publish the superproject using my clone of subproject, I have\nto create a new commit, which would have a different hash from the origin.\nSo how do people know they can trust my tree?\nAnd what happens when the original super-project pulls from me -\nit seems that his .gitmodules will now point to my server?\n\n> The override system is only there for the local repository (which always takes \n> precedence) not for the server provider to hide detail from those checking \n> the repo out.\n\nI really like it that currently, in git, there is no difference between a public\nand local repository. If the override system is only for the local repository,\nwe create a difference here - doesn't this break the distributed nature of git?\n\nTake offline work as an example:\n\nSo I have have cloned the supermodule and the submodule to my laptop -\nit's enough to edit .git/config and I can use the history locally - that's good.\nBut now I try to clone the local tree - and a clone will try to go out\nto the URL which I cloned - bad.\n\n-- \nMST\n"},{"id":"42459","messageId":"200705181118.17307.Josef.Weidendorfer@gmx.de","threadId":"8181","inReplyTo":"20070518045025.GT4489@pasky.or.cz","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-05-18T09:18:17Z","receivedAt":"2007-05-18T09:18:17Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 18 May 2007, Petr Baudis wrote:\n> The problem is ugly too, though - suddenly, you have created a SINGLE\n> UNIVERSE-WIDE NAMESPACE INSIDE A DISTRIBUTED VCS. And that's not going\n> to work well.\n\nActually, tags are already such a namespace. If you want to merge\ntwo projects which have the same tag names, of course you still\npreserve the different tag objects, but only one will appear in the\nrefs/tags namespace.\n\nSo what is the best identifier for a subprobject? It is one that\nprobably never clashes with any subproject identifier of another\nsuperproject. At least, it should not clash between any superprojects\nwhich ever could be a candidate for merging the two into one.\n\nJunios proposal using an URL as identifier actually is quite good in\nthis regard, similar to JAVA package names.\n\nHowever, I wonder whether the possible merge of two superprojects\ninto one is a real issue. When they use the same subprojects identifiers,\nthere is a workaround: instead of merging, make one superproject the\nsubproject of the other.\n\nJosef\n"},{"id":"42460","messageId":"200705181021.30062.andyparkins@gmail.com","threadId":"8181","inReplyTo":"200705181043.09203.Josef.Weidendorfer@gmx.de","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-18T09:21:28Z","receivedAt":"2007-05-18T09:21:28Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 May 18, Josef Weidendorfer wrote:\n\n> It all depends on how we construct the default URL out of the subproject\n> identifier. Options:\n> (1) do not try to construct a default URL at all. Error out without a\n> config (2) use a configurable rewriting scheme like s/(.*)/git://host/\\1/\n> (3) automatically detect a senseful rewriting scheme\n>\n> Let's start with (1). We can invent convenient default schemes later on.\n\nAll good; except let's start with \n\n (1) if no config, try using the key itself - error out if that fails\n\nThen everybody is happy - if you want to use your system where the key is not \na URL, then don't - you'll get the error you want. If the user chose to use \na URL then magic will happen.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"42461","messageId":"200705181040.37648.andyparkins@gmail.com","threadId":"8181","inReplyTo":"20070518085708.GC4708@mellanox.co.il","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-18T09:40:36Z","receivedAt":"2007-05-18T09:40:36Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 May 18, Michael S. Tsirkin wrote:\n\n> > I think that's the wrong solution. A change of source URL for a\n> > submodule from what upstream uses to your own server is a _fork_ from\n> > upstream, therefore you would fork your own branch in your supermodule\n> > and alter .gitmodules to point at your server. Everybody is happy, and\n> > the fork is recorded.\n>\n> Why should I record it? If the content is the same, the commit name should\n> be the same, it shouldn't matter where did the content came from.\n\nBecause you have changed something that the upstream repository supplied with \nno way of detecting it. It's the same as if upstream supplied \nimportant_login_function.c and then you clone it; if your clone had a way of \nchanging important_login_function.c to add a backdoor and passing that to \npeople who clone from you without changing the commit hash that would be bad.\n\nSubmodules is the same; upstream might say\n kernel git://git.kernel.org/kernel-2.6.git\nThen you clone it and use the override system to override that to\n kernel git://git.dodgykernel.org/backdoors.git\nwithout having to change the repository.\n\nThe server should not be allowed to override the url that the client sees. \nOnly the client should make that decision.\n\n> I wouldn't be happy: I have just cloned both project and superproject,\n> but to re-publish the superproject using my clone of subproject, I have\n> to create a new commit, which would have a different hash from the origin.\n> So how do people know they can trust my tree?\n\nThat problem exists regardless of the method of changing URL - in your method \nthough the change is entirely unrecorded because you've changed something \nthat upstream supplied in an out-of-band manner.\n\n> And what happens when the original super-project pulls from me -\n> it seems that his .gitmodules will now point to my server?\n\nNow that one is a good defence. Okay; I accept that changing .gitmodules \nwon't work. However, I don't accept that the server should be allowed to \nsupply overrides to the client. Another method is needed.\n\n> > The override system is only there for the local repository (which always\n> > takes precedence) not for the server provider to hide detail from those\n> > checking the repo out.\n>\n> I really like it that currently, in git, there is no difference between a\n> public and local repository. If the override system is only for the local\n\nOf course there is a difference. .git/config is different; .git/refs is \ndifferent; .git/info/exclude is different; etc. These are all per-repository \nsettings - and there is no way for a server to force it's version of those \nfiles on a client.\n\n> So I have have cloned the supermodule and the submodule to my laptop -\n> it's enough to edit .git/config and I can use the history locally - that's\n> good. But now I try to clone the local tree - and a clone will try to go\n> out to the URL which I cloned - bad.\n\nYep. That is the problem. In the end the only practical solution might be to \nallow the server to supply part of the .git/config (which is essentially what \nyour suggestion would do); but I think that that is a big step to take and \nhas potential to be abused.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"42463","messageId":"464D7CFA.B983778B@eudaptics.com","threadId":"8181","inReplyTo":"200705181040.37648.andyparkins@gmail.com","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-18T10:16:26Z","receivedAt":"2007-05-18T10:16:26Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Andy Parkins wrote:\n> On Friday 2007 May 18, Michael S. Tsirkin wrote:\n> > I wouldn't be happy: I have just cloned both project and superproject,\n> > but to re-publish the superproject using my clone of subproject, I have\n> > to create a new commit, which would have a different hash from the origin.\n> > So how do people know they can trust my tree?\n> \n> That problem exists regardless of the method of changing URL - in your method\n> though the change is entirely unrecorded because you've changed something\n> that upstream supplied in an out-of-band manner.\n\nAnd it doesn't matter: Once you trust the superproject with its\n.gitmodules (versioned or not), the trust is based on the SHA1 of the\ngitlink entry. Where the so named subproject commit came from is\nsecondary.\n\n-- Hannes\n"},{"id":"42467","messageId":"20070518110804.GD4708@mellanox.co.il","threadId":"8181","inReplyTo":"200705181021.30062.andyparkins@gmail.com","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-05-18T11:08:04Z","receivedAt":"2007-05-18T11:08:04Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting Andy Parkins :\n> Subject: Re: [3/4] What's not in 1.5.2 (new topics)\n> \n> On Friday 2007 May 18, Josef Weidendorfer wrote:\n> \n> > It all depends on how we construct the default URL out of the subproject\n> > identifier. Options:\n> > (1) do not try to construct a default URL at all. Error out without a\n> > config (2) use a configurable rewriting scheme like s/(.*)/git://host/\\1/\n> > (3) automatically detect a senseful rewriting scheme\n> >\n> > Let's start with (1). We can invent convenient default schemes later on.\n> \n> All good; except let's start with \n> \n> (1) if no config, try using the key itself - error out if that fails\n> \n> Then everybody is happy - if you want to use your system where the key is not \n> a URL, then don't - you'll get the error you want. If the user chose to use \n> a URL then magic will happen.\n\nI don't want an error. No one wants an error.\n\nI want to be able to clone a super project, a subproject,\nand use my copy of both instead of the original - including\ncloning my copy, pulls between such clones, being able to verify\nthat they are identical.\n\nWhat I *don't* want is a situation where the fact that original repository\nresides in north america necessarily means that everyone who looks at *my* clone\nof it will do a round trip to north america too.\n\nAnd this means that URLs must be out of tree, but does *not* mean that\ngit-daemon should not serve them for user's convenience.\n\nHow about an ability for git-daemon to get commands with git-config?\n\n-- \nMST\n"},{"id":"42468","messageId":"20070518112202.GE4708@mellanox.co.il","threadId":"8181","inReplyTo":"200705181040.37648.andyparkins@gmail.com","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-05-18T11:22:02Z","receivedAt":"2007-05-18T11:22:02Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> The server should not be allowed to override the url that the client sees. \n> Only the client should make that decision.\n\nWhy is that? Content is what is important. URLs are only a convenience measure\nto help clients find the content. The link must have a commit hash, so git can\n*verify* that the content is correct. Where it comes from must be irrelevant.\n\nSo if someone looks at my tree, and does not know where to get the content, he\nmight want my hint on this.\n\n\n-- \nMST\n"},{"id":"42473","messageId":"f2k4g6$879$2@sea.gmane.org","threadId":"8181","inReplyTo":"20070518045025.GT4489@pasky.or.cz","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-18T12:00:07Z","receivedAt":"2007-05-18T12:00:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: Petr Baudis , Josef Weidendorfer\n, \"Michael S. Tsirkin\" ,\nJunio C Hamano , Andy Parkins ,\nNicolas Pitre , git@vger.kernel.org]\n\nPetr Baudis wrote:\n> On Fri, May 18, 2007 at 02:32:53AM CEST, Steven Grimm wrote:\n\n>> For example -- and yes, this is partially a rehash of other people's \n>> ideas -- instead of mapping a subproject path directly to revision@URL, \n>> instead map it to revision@symbolic name. The symbolic name is then \n>> separately mapped to a URL, and it's that symbolic name that can be \n>> locally overridden. The mappings of symbolic names to URLs is \n>> unversioned; the mapping of subprojects to revision@symbolic is \n>> versioned. Local overrides happen at the symbolic->URL mapping.\n>> \n>> So you'd have something like\n>> \n>> version 1: kernel-src/ -> kernel24\n>> version 2: kernel-src/ -> kernel26\n>> unversioned:\n>> kernel24 -> git://whatever/2.4\n>> kernel26 -> git://whatever/2.6\n>> \n>> And then locally, the override is:\n>> \n>> kernel24 -> git://myhost/2.4\n> \n> Yes, this would be nice; in one of my first mails in this thread I\n> devoted a non-trivially large writeup to this, then proceeded to remove\n> it since this has a serious problem.\n> \n> Actually, Git already has a nice mechanism to handle these unversionaed\n> pointers - tags. Just make refs/tags/subproject/kernel24 containing the\n> URL to fetch. It's even easily overridable locally (and not easily\n> overridable remotely...).\n> \n> The problem is ugly too, though - suddenly, you have created a SINGLE\n> UNIVERSE-WIDE NAMESPACE INSIDE A DISTRIBUTED VCS. And that's not going\n> to work well. I think I don't have to elaborate too much - the\n> aforementioned FreeBSD people will have different ideas about kernels\n> than you, _you_ will have different idea about kernels in few tens of\n> years than now, then if you need to merge or probably even fetch, you\n> will get into big trouble.\n> \n> Notice that we don't have any such namespace right now (except the\n> D(SHA1) namespace, which is however possible only because it's so huge\n> _and_ the names are assigned automagically in a way that virtually\n> guarantees uniqueness across the whole universe) - tags come closest,\n> but there is nothing that fundamentally breaks when a clash happens\n> inside the namespace - it's just UI thing. But subproject names are\n> etched to the history - once you name it, you just can't get rid of it\n> forever.\n\nThere is a bit ugly solution for this: instead of using symbolic name\nin versioned .gitmodules for a subproject (for a repo), use subproject\nidentifier (inode), and put it in the tag object (or config) together with\nthe URL. Git would then search all the subproject / submodule info for\na given inode. You could have more than one inode / identifier name for\na subproject repo; this would avoid the \"independently created\" issue\nwith using inodes / file-ids in distributed SCM. One would have to\nensure however that different subprojects get assigned different inodes.\n\nThis is yet another level of indirection, and needs searching all the\nsubprojects info; but I don't think that there would be that many\nsubprojects used.\n\n\nBesides we make use of one such global namespace: version tags (although\nthey _could_ have different names, e.g. v0.6.0 and gitgui-0.6.0).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"42474","messageId":"200705181427.03598.Josef.Weidendorfer@gmx.de","threadId":"8181","inReplyTo":"20070518110804.GD4708@mellanox.co.il","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-05-18T12:27:03Z","receivedAt":"2007-05-18T12:27:03Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 18 May 2007, Michael S. Tsirkin wrote:\n> > Quoting Andy Parkins :\n> > Subject: Re: [3/4] What's not in 1.5.2 (new topics)\n> > \n> > On Friday 2007 May 18, Josef Weidendorfer wrote:\n> > \n> > > It all depends on how we construct the default URL out of the subproject\n> > > identifier. Options:\n> > > (1) do not try to construct a default URL at all. Error out without a\n> > > config (2) use a configurable rewriting scheme like s/(.*)/git://host/\\1/\n> > > (3) automatically detect a senseful rewriting scheme\n> > >\n> > > Let's start with (1). We can invent convenient default schemes later on.\n> > \n> > All good; except let's start with \n> > \n> > (1) if no config, try using the key itself - error out if that fails\n> > \n> > Then everybody is happy - if you want to use your system where the key is not \n> > a URL, then don't - you'll get the error you want. If the user chose to use \n> > a URL then magic will happen.\n> \n> I don't want an error. No one wants an error.\n\nHeh.\nOf course, a git-clone should come up with a URL in the local config\nsuch that subproject clones can happen without any an error.\n\nThe error would potentially happen after cloning if no config entry\nfor the URL can be found, e.g. when you decided at clone time to not\nfetch any subprojects, but do that later.\n\n> I want to be able to clone a super project, a subproject,\n> and use my copy of both instead of the original - including\n> cloning my copy, pulls between such clones, being able to verify\n> that they are identical.\n\nWhat about using user-global git configuration for this *before*\ngit-clone of the superprojects happens?\n\nLets say you have a clone of the linux-2.6 repository at ~/gitrepo/linux26,\nand you want to clone a superproject which includes linux-2.6 as subproject,\nusing \"linux26\" (or perhaps \"git://git.kernel.org/pub/linux-2.6.git\") as\nsubproject identifier.\nBefore cloning this superproject, you should be able to set up in ~/.gitconfig\n\n [project \"linux26\"]\n localurl = ~/gitrepo/linux26\n\nand the clone of the superproject should be able to use this repository as\nsubproject repository.\n\n> What I *don't* want is a situation where the fact that original repository\n> resides in north america necessarily means that everyone who looks at *my* clone\n> of it will do a round trip to north america too.\n\nSomeone which clones from you probably does not have access to \"~/gitrepo/linux26\",\nso you have to provide a public visible URL either way, like\n\n [project \"linux26\"]\n localurl = ~/gitrepo/linux26\n url = git://myhost/mylinux26.git\n\nand the \"url\" should be configured at the remote side at clone time.\n\nJosef\n"},{"id":"42478","messageId":"200705181336.01563.andyparkins@gmail.com","threadId":"8181","inReplyTo":"20070518112202.GE4708@mellanox.co.il","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-18T12:36:00Z","receivedAt":"2007-05-18T12:36:00Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 May 18, Michael S. Tsirkin wrote:\n\n> Why is that? Content is what is important. URLs are only a convenience\n> measure to help clients find the content. The link must have a commit\n> hash, so git can *verify* that the content is correct. Where it comes from\n> must be irrelevant.\n>\n> So if someone looks at my tree, and does not know where to get the content,\n> he might want my hint on this.\n\nTrue. Hannes also pointed out that the trust comes from the hash contained in \nthe gitlink that is in tree, there is no need to assign trust to the URL.\n\nI withdraw my objection.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"42479","messageId":"20070518124123.GX4489@pasky.or.cz","threadId":"8181","inReplyTo":"f2k4g6$879$2@sea.gmane.org","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-18T12:41:24Z","receivedAt":"2007-05-18T12:41:24Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, May 18, 2007 at 02:00:07PM CEST, Jakub Narebski wrote:\n> There is a bit ugly solution for this: instead of using symbolic name\n> in versioned .gitmodules for a subproject (for a repo), use subproject\n> identifier (inode), and put it in the tag object (or config) together with\n> the URL. Git would then search all the subproject / submodule info for\n> a given inode. You could have more than one inode / identifier name for\n> a subproject repo; this would avoid the \"independently created\" issue\n> with using inodes / file-ids in distributed SCM. One would have to\n> ensure however that different subprojects get assigned different inodes.\n\nWell, then it doesn't make any difference, no? You just renamed the\nproblem but it stays the same - to ensure uniqueness even across\nrepositories.\n\nOk, you can declare now that you will just think out a UUID for the\nsubproject, but aside of not fitting well with the whole git philosophy,\nthen you don't need the indirection again, just use the UUID as the tag\nname.\n\nI have the feeling that I'm missing something basic in your proposal...\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"42481","messageId":"20070518124609.GH4708@mellanox.co.il","threadId":"8181","inReplyTo":"200705181427.03598.Josef.Weidendorfer@gmx.de","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-05-18T12:46:09Z","receivedAt":"2007-05-18T12:46:09Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> > What I *don't* want is a situation where the fact that original repository\n> > resides in north america necessarily means that everyone who looks at *my* clone\n> > of it will do a round trip to north america too.\n> \n> Someone which clones from you probably does not have access to \"~/gitrepo/linux26\",\n> so you have to provide a public visible URL either way, like\n> \n> [project \"linux26\"]\n> localurl = ~/gitrepo/linux26\n> url = git://myhost/mylinux26.git\n> \n> and the \"url\" should be configured at the remote side at clone time.\n\nRight. In other words, urls for each project are unversioned file, and git-daemon\nneeds to be taught to serve them up (I think it already serves head names, which are\nunversioned too). Actually, can't something like what we do for remotes head\nnames work here as well?\n\n-- \nMST\n"},{"id":"42480","messageId":"20070518125836.GB4116@coredump.intra.peff.net","threadId":"8181","inReplyTo":"7vzm438evr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-18T12:58:36Z","receivedAt":"2007-05-18T12:58:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 17, 2007 at 11:49:12AM -0700, Junio C Hamano wrote:\n\n> > Instead, why not:\n> > 1. url location is supplied in configuration as\n> > [subproject \"kernel/\"]\n> > url = git://git.kernel.org/pub/linux-2.4.git\n> > 2. .gitmodules is simply read as a lower-priority version of\n> > configuration\n> \n> That does not support seeking back and forth between appliance\n> release #1 and release #2 which wants to say they want to bind\n> two different things at the same kernel/ path, does it?\n\nI had a vague notion that the subproject could hold _both_ of them,\nsince it's really the commits you're flipping between. But obviously\nthat has quite complex semantics, so now it's me doing the handwaving.\n\nWhat is the planned behavior when doing such a switch? I.e., if I have\nkernel/ bound to linux-2.6, and I do a 'git-checkout' back in time to a\nversion that wants linux-2.4 bound at kernel/, what will happen? Blowing\naway my subproject repo doesn't seem right.\n\n-Peff\n"},{"id":"42491","messageId":"20070518151044.2FC05111E33@yugib.highrise.ca","threadId":"8181","inReplyTo":"20070518110804.GD4708@mellanox.co.il","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Aidan Van Dyk","fromEmail":"aidan@highrise.ca","sentAt":"2007-05-18T15:06:53Z","receivedAt":"2007-05-18T15:06:53Z","isPatch":false,"sender":{"key":"aidan@highrise.ca","avatar":"https://gravatar.com/avatar/853c50d90cce753dc1c390fdc6cbed558f5f969bd43fa4f5cb0118d8f71316f6?d=mp&s=160"},"body":"Michael S. Tsirkin wrote:\n\n>> Quoting Andy Parkins :\n>> Subject: Re: [3/4] What's not in 1.5.2 (new topics)\n>> \n>> On Friday 2007 May 18, Josef Weidendorfer wrote:\n>> \n>> > It all depends on how we construct the default URL out of the\n>> > subproject identifier. Options:\n>> > (1) do not try to construct a default URL at all. Error out without a\n>> > config (2) use a configurable rewriting scheme like\n>> > s/(.*)/git://host/\\1/ (3) automatically detect a senseful rewriting\n>> > scheme\n>> >\n>> > Let's start with (1). We can invent convenient default schemes later\n>> > on.\n>> \n>> All good; except let's start with\n>> \n>> (1) if no config, try using the key itself - error out if that fails\n>> \n>> Then everybody is happy - if you want to use your system where the key is\n>> not\n>> a URL, then don't - you'll get the error you want. If the user chose to\n>> use a URL then magic will happen.\n> \n> I don't want an error. No one wants an error.\n> \n> I want to be able to clone a super project, a subproject,\n> and use my copy of both instead of the original - including\n> cloning my copy, pulls between such clones, being able to verify\n> that they are identical.\n> \n> What I *don't* want is a situation where the fact that original repository\n> resides in north america necessarily means that everyone who looks at *my*\n> clone of it will do a round trip to north america too.\n\nAgain - if *I* create a project, and decide to use a particular key for a\nsubproject, then good. If *you* create a project and decide to use a\nparticular key for a subproject, then good. \n\nIf you clone *my* superproject, you get *my* choice of key. If I clone\n*your* superproject, I get *your* choice of key.\n\nThe fact that I can choose a URL as my key is in no way influencing the fact\nthat you can choose to *not* use a URL for your key.\n\nAnd if if you want to \"copy\" my project, but \"change\" the key for the\nsubproject, that's something you can too to! In GIT, that's a branch.\n"},{"id":"42492","messageId":"20070518153134.GM4708@mellanox.co.il","threadId":"8181","inReplyTo":"20070518151044.2FC05111E33@yugib.highrise.ca","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-05-18T15:31:34Z","receivedAt":"2007-05-18T15:31:34Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Again - if *I* create a project, and decide to use a particular key for a\n> subproject, then good. If *you* create a project and decide to use a\n> particular key for a subproject, then good. \n> \n> If you clone *my* superproject, you get *my* choice of key. If I clone\n> *your* superproject, I get *your* choice of key.\n\nAbsolutely. What I object to is using this key in clients\nas a hint for where to get the objects.\nThis *must* be overridable by me, without creating commits.\n\n-- \nMST\n"},{"id":"42494","messageId":"20070518160840.GK18276@pasky.or.cz","threadId":"8181","inReplyTo":"200705181751.15435.Josef.Weidendorfer@gmx.de","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2007-05-18T16:08:40Z","receivedAt":"2007-05-18T16:08:40Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, May 18, 2007 at 05:51:14PM CEST, Josef Weidendorfer wrote:\n> On Friday 18 May 2007, Michael S. Tsirkin wrote:\n> > > Subproject identifiers appear in versioned .gitmodule files, so\n> > > they are fixed with the history of the project. You can not change\n> > > the names without rewriting history.\n> > \n> > Actually, I think this means that moving the\n> > directory where the subproject resides will involve\n> > editing .gitmodule. I sthat true?\n> \n> Yes.\n> This was a design decision by Linus. The alternative way\n> would have been a separate gitlink object, which includes the\n> commit SHA1 of the subproject _and_ a subproject identifier,\n> thus increasing the number of objects.\n> \n> The current way is far simpler, but you have to edit the .gitmodule\n> file when moving subprojects around. The argument by Linus was\n> that this inconvenience should be acceptable as moving subprojects\n> around should only happen very few times in the lifetime of a\n> project, and involves heavy rearranging either way, such that editing\n> .gitmodules info is the smaller issue.\n\nFurthermore, git mv can trivially take care of this anyway...\n\n> > This would be annoying. \n> > \n> > Can't a project name be a git attribute for the gitlink object?\n> \n> Of course. The name can be put into the .gitattributes file instead of\n> a separate .gitmodules file.\n> \n> > This way I can move the object and it keeps the project name.\n> \n> No.\n> Git attributes do not magically move around when you move files or\n> directories. You always have to change the .gitattribute file too, if\n> you want to move attributes with files. Of course, this is not needed\n> if you use glob patterns in .gitattributes which also fits for moved\n> files. \n\nActually, git-mv might take care of this too? ;-) (Would it be\nconsidered a Bad Thing, or should I whip up a patch?)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"42495","messageId":"20070518162106.GN4708@mellanox.co.il","threadId":"8181","inReplyTo":"20070518160840.GK18276@pasky.or.cz","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-05-18T16:21:06Z","receivedAt":"2007-05-18T16:21:06Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> > The current way is far simpler, but you have to edit the .gitmodule\n> > file when moving subprojects around. The argument by Linus was\n> > that this inconvenience should be acceptable as moving subprojects\n> > around should only happen very few times in the lifetime of a\n> > project, and involves heavy rearranging either way, such that editing\n> > .gitmodules info is the smaller issue.\n> \n> Furthermore, git mv can trivially take care of this anyway...\n\nGood idea.\n\n-- \nMST\n"},{"id":"42496","messageId":"7vejle6p96.fsf@assigned-by-dhcp.cox.net","threadId":"8181","inReplyTo":"200705181043.09203.Josef.Weidendorfer@gmx.de","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-18T17:00:21Z","receivedAt":"2007-05-18T17:00:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer writes:\n\n> On Friday 18 May 2007, Andy Parkins wrote:\n>> Bear in mind that what you're suggesting is no different in implementation \n>> >from what Junio is suggesting but with one difference: in Junio's option \n>> the \"identifier\" will act as a default URL if no override is found.\n>\n> Yes; actually, its exactly the same aside from the name used in .gitmodules\n> for it, as I proposed a default URL which is derived from the suproject identifier\n> if no config entry is found.\n>\n>> > Again, we could have a default URL in the absence of this config entry\n>> > which is relative to the URL of the superproject, and which allows for the\n>> > superproject repository to act as proxy.\n>> \n>> This is why Junio's option of URL=Key is better.\n\nThere is one thing that three-level thing Steven Grimm suggested\nsolves cleaner that my strawman would not.\n\nIf the superproject is about building a live-cd that hosts two\ndifferent systems, one BSD and the other Linux, you would have:\n\n\tkernel-bsd/ subproject pointing at http://some.bsd.org/\n kernel-linux/ pointing at http://www.kernel.org/kernel/\n\nNow suppose kernel.org people forgot to renew the domain\nregistration and BSD people are quick to react, takes over the\nnice \"kernel.org\" domain, and now the latter URL becomes a site\nabout the BSD kernel---what happens? ;-) URL=Key scheme uses the\nURL as the key so newer kernel-bsd/ subproject may be pointed at\nby http://www.kernel.org/kernel/ in the superproject after such\na transition. Linux kernel wouldn't cease to be served, so\nin your .git/config you will a map to tell git to fetch from the\nnew location http://www.linux-kernel.org/kernel, but what key\nwould you use? Using http://www.kernel.org/kernel/ would not be\ncorrect as it would work only for older parts of the history.\nNewer part of the history would want to map the same URL (=Key)\nto http://www.kernel.org/kernel which is now hosting the BSD\nkernel.\n\nIn short, you would need to be able to express the \"intent\" in\nthe .gitmodules and say \"I am talking about the Linux kernel\nwith this entry\", and if the same URL used for that purpose is\never retargetted to house something different that is also used\nin your superproject, URL=Key scheme is screwed.\n\nAlso I would be lying if I said I do not like the three-level\nthing --- that was one of the options I considered before the\nURL=Key thing. Steven's three-level thing does not have the\nabove problem (but there is one thing you need to be careful\nabout, which I'll mention at the end of this discussion).\n\n> It all depends on how we construct the default URL out of the subproject\n> identifier. Options:\n> (1) do not try to construct a default URL at all. Error out without a config\n> (2) use a configurable rewriting scheme like s/(.*)/git://host/\\1/\n> (3) automatically detect a senseful rewriting scheme\n>\n> Let's start with (1). We can invent convenient default schemes later on.\n\nMy preference is to stay at (1), and even if we are to do the\nlater steps, do it _always_ with confirmation from the user.\n\nFetching from a new URL (not just \"different from what is\ndefined in .gitmodules\") is a major deal from security point of\nview (you should not fetch from stranger you do not trust).\n\nThere is one thing that I sense was misunderstood by some people\nabout my original strawman. Entries in .git/config are _not_\nused as an override. They _are_ the only thing that are used.\n\nLet's forget the above \"BSD takes over kernel.org\" example,\nwhich was a tongue-in-cheek, and go back to the original\nappliance release #1 and #2 uses kernel 2.4 and 2.6 example.\n\nWhen you see this in .gitmodule:\n\n \t[subproject \"kernel/\"]\n \tURL = git://git.kernel.org/pub/linux-2.4.git\n \nyou can be in three states:\n\n (1) You haven't known about this subproject's URL.\n\n (2) You have already known about this subproject, and you\n earlier decided not to clone it nor check it out (i.e. in\n your working tree, kernel/ subdirectory is left empty).\n By default, you do not want to be bothered by this\n subproject.\n\n (3) You have known about this subproject, and you earlier\n decided that you are interested in it. You have a\n repository and working tree that represents the subproject\n checked out in your kernel/ subdirectory. By default, you\n want to keep track of this subproject.\n\nObviously in the initial-clone case you can only be in state\n(1). After the initial clone, if the upstream changed the\nkernel/ binding to point at 2.6 kernel tree, you are also in the\nsame state (1).\n\nIn these cases, since the upstream clearly states that they are\nnow talking about a project unknown to you so far, or talking\nabout a different project (it could be just a new location for\nthe same thing, the case Steven's three-level thing can help you\nto differenciate with this), I DO NOT want git to automatically\nsay \"Ok, that's the new location\" and blindly start following.\n\nAn unattended pull (actually, the checkout step after a pull)\nSHOULD error out.\n\nAn interactive case should give an easy way for the user to\nexpress his preference: (a) I do not care about this subproject,\n(b) I do want to have this cloned and checked out, and the\nsuggested URL in .gitmodules would work fine for me, or (c) I do\nwant to have this, but I want to use this other URL because I\nhave a local mirror already.\n\nI wrote in my original strawman to have these two entries in the\n.git/config file:\n\n \t[subproject \"git://git.kernel.org/pub/linux-2.4.git\"]\n \tURL = http://www.kernel.org/pub/linux-2.4.git\n \nThe example mapped the URL=Key to a different URL, which gave a\nfalse impression that I was only talking about override, but\nthat was my fault. My intention was to use the _presense_ of\nsubproject.$URL section in .git/config as a way to detect state\n(1), so when the user says \"I do want to follow this subproject\nand the .gitmodules URL is Ok\" (iow, choice (b) above), you\nwould have an identical \"mapping\" there:\n\n \t[subproject \"git://git.kernel.org/pub/linux-2.4.git\"]\n \tURL = git://git.kernel.org/pub/linux-2.4.git\n\nThat's not an \"override\". Lack of these two lines does not mean\nyou will blindly follow kernel/ subproject using the URL\nrecorded in .gitmodules file; it means you haven't decided what\nto do about the kernel/ subproject yet.\n\nIf the user wants to say \"I am not interested\" (iow, choice (a)\nabove), we would not have URL section, but explicit variable to\nsay \"I am not interested\" there, like this:\n\n \t[subproject \"git://git.kernel.org/pub/linux-2.4.git\"]\n \tignored\n\nThen the presense of this section tells us that we are not in\nstate (1) about this subproject.\n\nThe above can easily be rewritten to use Steven's three-level\nscheme, which I tend to think would work better. But if we were\nto do that, I think the .git/config section should give you a\nway to differentiate not just known/unknown subprojects but also\na way to differentiate known/unknown URLs.\n\nIOW, .gitmodules in three-level scheme might say:\n\n\t[subproject \"kernel/\"]\n \tname = linux-2.6\n URL = git://git.kernel.org/pub/linux-2.6.git\n\nand your .git/config would say:\n\n\t[subproject \"linux-2.6\"]\n URL = http://www.kernel.org/pub/linux-2.6.git\n seen = git://git.kernel.org/pub/linux-2.6.git\n\nso that when the upstream .gitmodules changed the suggested URL\nto \"git://git.or.cz/pub/linux-2.6.git\", the UI can say:\n\n\tThe project uses \"linux-2.6\" project at kernel/\n\tsubdirectory as subproject, we already know that you are\n\tinterested in tracking it, that you have been tracking\n\tit with http://www.kernel.org/pub/linux-2.6.git URL.\n\tThe upstream suggests a new URL you haven't seen, which is\n\t\"git://git.or.cz/pub/linux-2.6.git\". Do you want to\n\tadjust the URL to follow this subproject?\n\nThe user may say yes and tell git to use http:// instead, in\nwhich case the section in .git/config would become:\n\n\t[subproject \"linux-2.6\"]\n URL = http://git.or.cz/pub/linux-2.6.git\n seen = git://git.kernel.org/pub/linux-2.6.git\n\t\tseen = git://git.or.cz/pub/linux-2.6.git\n\nAfter that, if the upstream wags the entry .gitmodules back to\npoint at git.kernel.org/, you already know about that repository\nand the UI does not have to ask you what to do about it. That's\nmade possible by using URL=Key in my strawman, but needs to be\ndone by this extra 'seen' multi-value variables in the three-level\nscheme.\n"},{"id":"42502","messageId":"7vwsz65679.fsf@assigned-by-dhcp.cox.net","threadId":"8181","inReplyTo":"f2k4g6$879$2@sea.gmane.org","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-18T18:37:14Z","receivedAt":"2007-05-18T18:37:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> [Cc: Petr Baudis , Josef Weidendorfer\n> , \"Michael S. Tsirkin\" ,\n> Junio C Hamano , Andy Parkins ,\n> Nicolas Pitre , git@vger.kernel.org]\n\nOfftopic. Why do you do this, and what benefit are you or\nanybody in the above list, which is in body part of the message,\ngetting?\n"},{"id":"42503","messageId":"Pine.LNX.4.64.0705181939250.14963@beast.quantumfyre.co.uk","threadId":"8181","inReplyTo":"7vwsz65679.fsf@assigned-by-dhcp.cox.net","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-05-18T18:40:31Z","receivedAt":"2007-05-18T18:40:31Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Fri, 18 May 2007, Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n>\n>> [Cc: Petr Baudis , Josef Weidendorfer\n>> , \"Michael S. Tsirkin\" ,\n>> Junio C Hamano , Andy Parkins ,\n>> Nicolas Pitre , git@vger.kernel.org]\n>\n> Offtopic. Why do you do this, and what benefit are you or\n> anybody in the above list, which is in body part of the message,\n> getting?\n\nIt looks like he is posting through gmane using a news reader ... so the \nlist post comes from gmane while the CCs go out directly (I assume).\n\n-- \nJulian\n\n ---\nGreen's Law of Debate:\n \tAnything is possible if you don't know what you're talking about.\n"},{"id":"42504","messageId":"7vsl9u55tv.fsf@assigned-by-dhcp.cox.net","threadId":"8181","inReplyTo":"Pine.LNX.4.64.0705181939250.14963@beast.quantumfyre.co.uk","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-18T18:45:16Z","receivedAt":"2007-05-18T18:45:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julian Phillips writes:\n\n> On Fri, 18 May 2007, Junio C Hamano wrote:\n>\n>> Jakub Narebski writes:\n>>\n>>> [Cc: Petr Baudis , Josef Weidendorfer\n>>> , \"Michael S. Tsirkin\" ,\n>>> Junio C Hamano , Andy Parkins ,\n>>> Nicolas Pitre , git@vger.kernel.org]\n>>\n>> Offtopic. Why do you do this, and what benefit are you or\n>> anybody in the above list, which is in body part of the message,\n>> getting?\n>\n> It looks like he is posting through gmane using a news reader ... so\n> the list post comes from gmane while the CCs go out directly (I\n> assume).\n\nAh, I see. The names listed on that in-body CC: do appear on\nthe To: in the copy of the message that came via e-mail. If\nthat is how gmane operates then there is nothing Jakub to do to\nimprove it, I guess...\n\nThanks for the clarification.\n"},{"id":"42576","messageId":"e7bda7770705181756h578c9766wb65b19f528699dc3@mail.gmail.com","threadId":"8181","inReplyTo":"200705181118.17307.Josef.Weidendorfer@gmx.de","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Torgil Svensson","fromEmail":"torgil.svensson@gmail.com","sentAt":"2007-05-19T00:56:39Z","receivedAt":"2007-05-19T00:56:39Z","isPatch":false,"sender":{"key":"torgil.svensson@gmail.com","avatar":null},"body":"On 5/18/07, Josef Weidendorfer wrote:\n> On Friday 18 May 2007, Petr Baudis wrote:\n> So what is the best identifier for a subprobject? It is one that\n> probably never clashes with any subproject identifier of another\n> superproject. At least, it should not clash between any superprojects\n> which ever could be a candidate for merging the two into one.\n\nPut all root-commit SHA1 in a file, call it something like \"project\nobject\" and take the SHA1 of that object the identifier. The\nSHA1-route has been successful so far as distributed \"keys\".\n\n//Torgil\n"},{"id":"42577","messageId":"464E4C94.5070408@midwinter.com","threadId":"8181","inReplyTo":"200705180857.18182.andyparkins@gmail.com","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-05-19T01:02:12Z","receivedAt":"2007-05-19T01:02:12Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Andy Parkins wrote:\n> Bear in mind that what you're suggesting is no different in implementation \n> from what Junio is suggesting but with one difference: in Junio's option \n> the \"identifier\" will act as a default URL if no override is found.\n> \n\nI don't like using the URL as the key for one simple reason: while it \ntechnically doesn't conflate the two cases of \"I want to use a different \ncode base for this subproject starting in version X of the superproject\" \nand \"I want to use the same code base I've been using all along, but it \nhas moved\" (in that you can, as you point out, simply map the old URL to \na new one independent of the project's history) it does encourage people \nto conflate the two in their minds.\n\nRelatively few users will look at an identifier that is a valid URL and \nthink of it as anything but a URL, especially if, in the absence of any \noverrides, the software (from the user's perspective) treats it as a \nURL. The override capability is almost certain to remain obscure since \nyou won't need to use it in the normal case. Therefore, when the \nsubmodule's home gets moved to a different host, the first thing a lot \nof people are going to think to do is not to leave the submodule's \nidentifier (the original URL) alone and create a mapping config entry, \nbut rather to change the submodule to use a brand-new identifier that \nhappens to be the same as the new URL. At which point you're right back \nto the original problem of checking out an old version of the \nsuperproject and having it point to a now-nonexistent subproject.\n\nThat's why I suggested making the identifiers look nothing like URLs, \nthough of course to the extent they're arbitrary strings, one could use \na URL if one chose to. I don't object to the *capability* of using a URL \nas an identifier in a three-level scheme like I described -- it would be \nsilly to forbid -- but I think it would be a dangerous convention to \nestablish because it will eventually encourage people to shoot \nthemselves in the foot for lack of knowing what's actually going on.\n\n-Steve\n"},{"id":"42621","messageId":"20070519125055.GQ942MdfPADPa@greensroom.kotnet.org","threadId":"8181","inReplyTo":"20070518110804.GD4708@mellanox.co.il","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2007-05-19T12:50:55Z","receivedAt":"2007-05-19T12:50:55Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Fri, May 18, 2007 at 02:08:04PM +0300, Michael S. Tsirkin wrote:\n> How about an ability for git-daemon to get commands with git-config?\n\nYou mean something like dump-config ?\n\nskimo\n"},{"id":"42655","messageId":"200705191838.50797.jnareb@gmail.com","threadId":"8181","inReplyTo":"20070518124123.GX4489@pasky.or.cz","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-19T16:38:50Z","receivedAt":"2007-05-19T16:38:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 18 May 2007, Petr Baudis wrote:\n> On Fri, May 18, 2007 at 02:00:07PM CEST, Jakub Narebski wrote:\n\n>> There is a bit ugly solution for this: instead of using symbolic name\n>> in versioned .gitmodules for a subproject (for a repo), use subproject\n>> identifier (inode), and put it in the tag object (or config) together with\n>> the URL. Git would then search all the subproject / submodule info for\n>> a given inode. You could have more than one inode / identifier name for\n>> a subproject repo; this would avoid the \"independently created\" issue\n>> with using inodes / file-ids in distributed SCM. One would have to\n>> ensure however that different subprojects get assigned different inodes.\n> \n> Well, then it doesn't make any difference, no? You just renamed the\n> problem but it stays the same - to ensure uniqueness even across\n> repositories.\n> \n> Ok, you can declare now that you will just think out a UUID for the\n> subproject, but aside of not fitting well with the whole git philosophy,\n> then you don't need the indirection again, just use the UUID as the tag\n> name.\n> \n> I have the feeling that I'm missing something basic in your proposal...\n\nI was thinking about _automatic_ UUID, generated by git. For example it\ncould be sha1 of first subproject commit which appeared in supermodule.\nIt is easy to check if two UUID correspond to the same repository:\ncheck if both objects are present, or perhaps that one is reachable from\nthe other, or that they have common parent. This kind of UUID is not\nthat different from (global) SHA1 of object.\n\nSo the idea is to have versioned, i.e. in-tree mapping from directory\nnames to repositories via some kind of identifier: Junio idea of using\nURL of repository, with possibility of overriding it in repo config,\nthe idea of using tag name, and having URL for repo in tag contents,\nand my idea of tag name of tag containing UUID. To find the URL you\nwould search all the repo-tags for UUID, or for existence of commit\nwith given sha1.\n\nBut I haven't thought this idea through, so it migh be utter rubbish.\n\n\nThe porcelain part of subproject / submodule support is not that\neasy, to cover for moving subproject \"mountpoint\", project changing URL,\nconflict of project names and different naming of the same project etc.\n-- \nJakub Narebski\nPoland\n"},{"id":"42632","messageId":"200705191855.35104.Josef.Weidendorfer@gmx.de","threadId":"8181","inReplyTo":"464E4C94.5070408@midwinter.com","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-05-19T16:55:34Z","receivedAt":"2007-05-19T16:55:34Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Saturday 19 May 2007, Steven Grimm wrote:\n> Andy Parkins wrote:\n> > Bear in mind that what you're suggesting is no different in implementation \n> > from what Junio is suggesting but with one difference: in Junio's option \n> > the \"identifier\" will act as a default URL if no override is found.\n> > \n> \n> I don't like using the URL as the key for one simple reason:\n> ...\n\nAnother argument against naming the key for subprojects \"URL\" in\nconfig/.gitmodules:\nIt can happen quite easily that a superprojects includes 2 subprojects\nwhich really are only different branches of the same project, e.g.\nGCC 4.1 and GCC 4.2 branch, e.g. to do regression testing with different\ncompiler versions.\nBut these two subprojects would be cloned from exactly the same URL.\nSo you artificially have to change one of the two URLs for this to\nwork, already at the start of your subproject.\n\nThe same example shows that the SHA1 of a projects root commit can not\nwork as a subproject key.\n\nJosef\n"},{"id":"42636","messageId":"20070519181228.GP4708@mellanox.co.il","threadId":"8181","inReplyTo":"7vejle6p96.fsf@assigned-by-dhcp.cox.net","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-05-19T18:12:28Z","receivedAt":"2007-05-19T18:12:28Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Fetching from a new URL (not just \"different from what is\n> defined in .gitmodules\") is a major deal from security point of\n> view (you should not fetch from stranger you do not trust).\n\nI'm sorry, I'm confused. I thought the \"URL\" in .gitmodules\nis just a unique project key/name? So how come you are now\nspeaking about fetching from it?\n\n-- \nMST\n"},{"id":"42641","messageId":"7vejlcwpry.fsf@assigned-by-dhcp.cox.net","threadId":"8181","inReplyTo":"20070519181228.GP4708@mellanox.co.il","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-19T19:56:49Z","receivedAt":"2007-05-19T19:56:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" writes:\n\n>> Fetching from a new URL (not just \"different from what is\n>> defined in .gitmodules\") is a major deal from security point of\n>> view (you should not fetch from stranger you do not trust).\n>\n> I'm sorry, I'm confused. I thought the \"URL\" in .gitmodules\n> is just a unique project key/name? So how come you are now\n> speaking about fetching from it?\n\nSorry for confusing you. The point was by default that we\nshould not blindly follow URL given from upstream -- the\nstatement you quoted is one justification why my strawman uses\nthe URL in .gitmodules as a mere hint and look-up key.\n\nHaving said that, I'd ask not to take minor details in the\nstrawman too literally and seriously. I am 100% sure that we\nwould be in a serious trouble if what we end up doing matches\nliterally what my handwaving strawman suggested. The strawman\nwas thrown out to the open primarily so that (smarter and more\nbeautiful) people who thought the issues longer and harder to\nexpress their opinions easier by having something to compare\ntheir unique ideas against, nothing more.\n\nI am slightly more than 50% sure that we would not want to tie\nsubproject fetch/clone into superproject fetch/clone, and _if_\nwe would tie it to anything, it would be to the checkout, but\nthat is only my gut feeling. Maybe we end up not tying\nsubproject fetch/clone to anything that happens in the\nsuperproject; we may even do it in a completely different way\nthan the strawman said it _might_ work. That's perfectly fine.\n\nThe expectation from me sending out that handwaving strawman was\nto help encouraging others to present their ideas, with\njustifications. And having something to compare against, even\nif it is just a handwaving strawman, is often much easier when\npresenting your ideas and showing which part of your design is\nimportant. You can say something like \"the strawman fails in\nthis scenario, which is important in real life for such and such\nreasons, and my design handles it this way\" -- and everybody\ncan discuss if it is an important design consideration, and what\nthe best design to solve that problem if it is.\n\nSo don't take that strawman, especially the details in it, too\nseriously, but take it as what it was: a firestarter.\n"},{"id":"42662","messageId":"20070520001610.GD4489@pasky.or.cz","threadId":"8181","inReplyTo":"7vsl9u55tv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-20T00:16:10Z","receivedAt":"2007-05-20T00:16:10Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, May 18, 2007 at 08:45:16PM CEST, Junio C Hamano wrote:\n> Julian Phillips writes:\n> \n> > On Fri, 18 May 2007, Junio C Hamano wrote:\n> >\n> >> Jakub Narebski writes:\n> >>\n> >>> [Cc: Petr Baudis , Josef Weidendorfer\n> >>> , \"Michael S. Tsirkin\" ,\n> >>> Junio C Hamano , Andy Parkins ,\n> >>> Nicolas Pitre , git@vger.kernel.org]\n> >>\n> >> Offtopic. Why do you do this, and what benefit are you or\n> >> anybody in the above list, which is in body part of the message,\n> >> getting?\n> >\n> > It looks like he is posting through gmane using a news reader ... so\n> > the list post comes from gmane while the CCs go out directly (I\n> > assume).\n> \n> Ah, I see. The names listed on that in-body CC: do appear on\n> the To: in the copy of the message that came via e-mail. If\n> that is how gmane operates then there is nothing Jakub to do to\n> improve it, I guess...\n> \n> Thanks for the clarification.\n\nActually, Jakub, if it can be turned off, could you, please?\n\nNot getting cc'd on replies is slightly annoying. But this is highly\nconfusing - suddenly I must take care _not_ to reply to the private\ncopies, and we actually do have a parallel subthread of replies to your\nmail not cc'd to the mailing list. :-(\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"42832","messageId":"f2qr8h$cep$1@sea.gmane.org","threadId":"8181","inReplyTo":"20070519125055.GQ942MdfPADPa@greensroom.kotnet.org","subject":"Re: [3/4] What's not in 1.5.2 (new topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-21T01:10:18Z","receivedAt":"2007-05-21T01:10:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sven Verdoolaege wrote:\n\n> On Fri, May 18, 2007 at 02:08:04PM +0300, Michael S. Tsirkin wrote:\n>> How about an ability for git-daemon to get commands with git-config?\n> \n> You mean something like dump-config ?\n\nWhy not use tags, e.g. refs/tags/config tag to blob, or lightweight\ntag to blob?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"43225","messageId":"200705251155.36835.jnareb@gmail.com","threadId":"8181","inReplyTo":"20070520001610.GD4489@pasky.or.cz","subject":"News reader woes (was: Re: [3/4] What's not in 1.5.2 (new topics))","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-25T09:55:35Z","receivedAt":"2007-05-25T09:55:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 20 May 2007, Petr Baudis wrote:\n> On Fri, May 18, 2007 at 08:45:16PM CEST, Junio C Hamano wrote:\n>> Julian Phillips writes:\n>>> On Fri, 18 May 2007, Junio C Hamano wrote:\n>>>> Jakub Narebski writes:\n>>>>\n>>>>> [Cc: Petr Baudis , Josef Weidendorfer\n>>>>> , \"Michael S. Tsirkin\" ,\n>>>>> Junio C Hamano , Andy Parkins ,\n>>>>> Nicolas Pitre , git@vger.kernel.org]\n>>>>\n>>>> Offtopic. Why do you do this, and what benefit are you or\n>>>> anybody in the above list, which is in body part of the message,\n>>>> getting?\n>>>\n>>> It looks like he is posting through gmane using a news reader ... so\n>>> the list post comes from gmane while the CCs go out directly (I\n>>> assume).\n>> \n>> Ah, I see. The names listed on that in-body CC: do appear on\n>> the To: in the copy of the message that came via e-mail. If\n>> that is how gmane operates then there is nothing Jakub to do to\n>> improve it, I guess...\n>> \n>> Thanks for the clarification.\n> \n> Actually, Jakub, if it can be turned off, could you, please?\n> \n> Not getting cc'd on replies is slightly annoying. But this is highly\n> confusing - suddenly I must take care _not_ to reply to the private\n> copies, and we actually do have a parallel subthread of replies to your\n> mail not cc'd to the mailing list. :-(\n\nThe problem, and mentioned above trying to overcome it, lies in\ncomplicated interaction between the GMane news to email gateway,\nvger mail filtering (spam protection rules) and the _news_ reader\nI use, namely KNode 0.10.2 from KDE 3.5.3.\n\nI read git mailing list via GMane NNTP (Usenet, news) interface:\n nntp://gmane.comp.version-control.git\nas I respond only rarely. I start new threads using email, and\nif I get reply via email I try to reply also from mail client, not\nvia news. However, when replying to message which I read only via\nNNTP interface, replying in news client, I have option of sending\nreply only to gmane.comp.version-control.git which means sending\nemail only to git mailing list and breaking Cc: list. \n\nAnother option is to copy Cc: list manually to To: field (no Cc:\nin this version of KNode), and have gmane.comp.version-control.git\nin the Group: field. The fact that there is no Cc: to set is the\nproblem of KNode. The problem with GMane and vger interaction lies\nin the fact that I _cannot_ put git@vger.kernel.org in the To: list,\nas somehow vger rejects mails sent via GMane (it does not rejects\nnews messages send via GMane).\n\nI could also copy whole message to mail client, but this would break\nIn-Reply-To: and references: headers, thus breaking threading.\n\n\nDo I understand correctly that you prefer 1st option, namely replying\nonly to newsgroup / git mailing list?\n\n\nNote that changing news client is as hard as changing email client:\nyou would like to migrate configuration, news state (read/unread\narticles) and sent/drafts folders to new news client. Not that easy.\n\n-- \nJakub Narebski\nPoland\n"}]}