{"thread":{"id":"2652","subject":"Question about handling of heterogeneous repositories","startedAt":"2005-11-22T16:50:24Z","lastAt":"2005-12-01T08:16:06Z","messageCount":11,"participants":["Alex Riesen","Andreas Ericsson","Petr Baudis","Josef Weidendorfer","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"12543","messageId":"81b0412b0511220850w429d2f36lafe9de7ce19ce8f@mail.gmail.com","threadId":"2652","inReplyTo":null,"subject":"Question about handling of heterogeneous repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-11-22T16:50:24Z","receivedAt":"2005-11-22T16:50:24Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Hi,\n\nit is sometimes the case that a project consists of parts which are\nunrelated to each other, and only thing in common between them is that\nthey all are used in that particular project. For example a program\nuses some library and the developer(s) of that program would like to\nhave the source of that library somewhere close. Well, for this simple\nexample one could just use two repositories, laid close to each other\nin a directory, like project/lib and project/prog.\nNow, if I make the example a bit more complex and say, that the\ndevelopers of the program are the developers in that project and\nchange everything under project/ directory, including\nproject/library/. They are also good people and ready to give the\nchanges to the library upstream.\n\nHow do they achieve that, without sending project/ and project/program/?\n\nFor everyone who have an experience with ClearCase or Perforce (I'm\nsorry for mentioning it) it is what the \"mappings\" are often used for:\na project is build together from different parts, which can be worked\non separately.\n\nI'm trying to introduce git at work, but have to prepare myself for\npossible questions first, and this is one of them :)\n\nGreetings,\nAlex Riesen\n"},{"id":"12560","messageId":"43837442.9060602@op5.se","threadId":"2652","inReplyTo":"81b0412b0511220850w429d2f36lafe9de7ce19ce8f@mail.gmail.com","subject":"Re: Question about handling of heterogeneous repositories","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-22T19:40:50Z","receivedAt":"2005-11-22T19:40:50Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Alex Riesen wrote:\n> Hi,\n> \n> it is sometimes the case that a project consists of parts which are\n> unrelated to each other, and only thing in common between them is that\n> they all are used in that particular project. For example a program\n> uses some library and the developer(s) of that program would like to\n> have the source of that library somewhere close. Well, for this simple\n> example one could just use two repositories, laid close to each other\n> in a directory, like project/lib and project/prog.\n> Now, if I make the example a bit more complex and say, that the\n> developers of the program are the developers in that project and\n> change everything under project/ directory, including\n> project/library/. They are also good people and ready to give the\n> changes to the library upstream.\n> \n> How do they achieve that, without sending project/ and project/program/?\n> \n> For everyone who have an experience with ClearCase or Perforce (I'm\n> sorry for mentioning it) it is what the \"mappings\" are often used for:\n> a project is build together from different parts, which can be worked\n> on separately.\n> \n> I'm trying to introduce git at work, but have to prepare myself for\n> possible questions first, and this is one of them :)\n> \n\nWe do like this;\n\ncore\ncore/gui\ncore/lib\n\n$ cat .gitignore\ngui\nlib\n\nThis is also nice because it lets the gui maintainers have the gui as \nthe root with the core and lib parts as subdirectories. Everyone has \ntheir own responsibility checked out at top-level with other pieces \nbelow it. It's easy enough to script a pull of all repos so everyone's \nup to sync and everybody's happy.\n\nIt would certainly be nicer to have git ignore directories that have the \n\".git\" directory (so long as it's not the top of the repo, that is), but \nI haven't had the energy to fix that when there's already a solution \nthat's simple enough and quite adequate.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12575","messageId":"20051122232228.GB2916@steel.home","threadId":"2652","inReplyTo":"43837442.9060602@op5.se","subject":"Re: Question about handling of heterogeneous repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-11-22T23:22:28Z","receivedAt":"2005-11-22T23:22:28Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Andreas Ericsson, Tue, Nov 22, 2005 20:40:50 +0100:\n> >it is sometimes the case that a project consists of parts which are\n> >unrelated to each other, and only thing in common between them is that\n> >they all are used in that particular project. For example a program\n> >uses some library and the developer(s) of that program would like to\n> >have the source of that library somewhere close. Well, for this simple\n> >example one could just use two repositories, laid close to each other\n> >in a directory, like project/lib and project/prog.\n> >Now, if I make the example a bit more complex and say, that the\n> >developers of the program are the developers in that project and\n> >change everything under project/ directory, including\n> >project/library/. They are also good people and ready to give the\n> >changes to the library upstream.\n> >\n> >How do they achieve that, without sending project/ and project/program/?\n> >\n> >For everyone who have an experience with ClearCase or Perforce (I'm\n> >sorry for mentioning it) it is what the \"mappings\" are often used for:\n> >a project is build together from different parts, which can be worked\n> >on separately.\n> >\n> >I'm trying to introduce git at work, but have to prepare myself for\n> >possible questions first, and this is one of them :)\n> >\n> \n> We do like this;\n> \n> core\n> core/gui\n> core/lib\n> \n> $ cat .gitignore\n> gui\n> lib\n> \n> This is also nice because it lets the gui maintainers have the gui as \n> the root with the core and lib parts as subdirectories. Everyone has \n> their own responsibility checked out at top-level with other pieces \n> below it. It's easy enough to script a pull of all repos so everyone's \n> up to sync and everybody's happy.\n\nAnd than, do you have to announce a special procedure everyone's is to\nexecute after a clone so all subrepos are cloned? How do you handle\ncommon configs and clone options in subrepos? It also would be nice to\nhave branches visible not only in in subrepos but in top-repo as well,\nand the other way around.\n\nI'm also wondering, what implications core/lib/.git/{config,remotes/,refs/}\nunder control in core/ can have?..\n\n> It would certainly be nicer to have git ignore directories that have the \n> \".git\" directory (so long as it's not the top of the repo, that is), but \n> I haven't had the energy to fix that when there's already a solution \n> that's simple enough and quite adequate.\n\nBTW, will something like \"*/.git/*\" in info/exclude work? IOW, does *\nmatch a \"/\"?\n"},{"id":"12796","messageId":"20051127131147.GF22159@pasky.or.cz","threadId":"2652","inReplyTo":"20051122232228.GB2916@steel.home","subject":"Re: Question about handling of heterogeneous repositories","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-27T13:11:47Z","receivedAt":"2005-11-27T13:11:47Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Nov 23, 2005 at 12:22:28AM CET, I got a letter\nwhere Alex Riesen <raa.lkml@gmail.com> said that...\n> Andreas Ericsson, Tue, Nov 22, 2005 20:40:50 +0100:\n> > >it is sometimes the case that a project consists of parts which are\n> > >unrelated to each other, and only thing in common between them is that\n> > >they all are used in that particular project. For example a program\n> > >uses some library and the developer(s) of that program would like to\n> > >have the source of that library somewhere close. Well, for this simple\n> > >example one could just use two repositories, laid close to each other\n> > >in a directory, like project/lib and project/prog.\n> > >Now, if I make the example a bit more complex and say, that the\n> > >developers of the program are the developers in that project and\n> > >change everything under project/ directory, including\n> > >project/library/. They are also good people and ready to give the\n> > >changes to the library upstream.\n> > >\n> > >How do they achieve that, without sending project/ and project/program/?\n> > >\n> > >For everyone who have an experience with ClearCase or Perforce (I'm\n> > >sorry for mentioning it) it is what the \"mappings\" are often used for:\n> > >a project is build together from different parts, which can be worked\n> > >on separately.\n> > >\n> > >I'm trying to introduce git at work, but have to prepare myself for\n> > >possible questions first, and this is one of them :)\n\nThis is something e.g. Cogito wants to support, but does not yet.\nPatches welcome.\n\n> > It would certainly be nicer to have git ignore directories that have the \n> > \".git\" directory (so long as it's not the top of the repo, that is), but \n> > I haven't had the energy to fix that when there's already a solution \n> > that's simple enough and quite adequate.\n> \n> BTW, will something like \"*/.git/*\" in info/exclude work? IOW, does *\n> match a \"/\"?\n\nNope, but try just '.git' - in case it is not a pathname but just a\nfilename (or dirname, for that matter), it will recursively apply to all\nthe subtrees.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"12944","messageId":"20051129204729.GA3033@steel.home","threadId":"2652","inReplyTo":"20051127131147.GF22159@pasky.or.cz","subject":"Re: Question about handling of heterogeneous repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-11-29T20:47:29Z","receivedAt":"2005-11-29T20:47:29Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Petr Baudis, Sun, Nov 27, 2005 14:11:47 +0100:\n> > > >For everyone who have an experience with ClearCase or Perforce (I'm\n> > > >sorry for mentioning it) it is what the \"mappings\" are often used for:\n> > > >a project is build together from different parts, which can be worked\n> > > >on separately.\n> > > >\n> > > >I'm trying to introduce git at work, but have to prepare myself for\n> > > >possible questions first, and this is one of them :)\n> \n> This is something e.g. Cogito wants to support, but does not yet.\n> Patches welcome.\n\nI wouldn't know what to patch, having no clear picture of the approach\nmyself, and especially when I don't feel safe using the solution. For\nexample, how do you go about moving/renaming files between subrepos?\nRename detection will not work, which will be unexpected...\n\nBTW, how does git-mv behave for out-of-tree renaming? How about\ninter-repo renaming (remove+add)?\n\n> > > It would certainly be nicer to have git ignore directories that have the \n> > > \".git\" directory (so long as it's not the top of the repo, that is), but \n> > > I haven't had the energy to fix that when there's already a solution \n> > > that's simple enough and quite adequate.\n> > \n> > BTW, will something like \"*/.git/*\" in info/exclude work? IOW, does *\n> > match a \"/\"?\n> \n> Nope, but try just '.git' - in case it is not a pathname but just a\n> filename (or dirname, for that matter), it will recursively apply to all\n> the subtrees.\n\nwell, it ignored the \".git\"s in the subdirs, not _the_ subdirectories.\nI think that can be helped by putting the directories themselves into\n.gitignore lists.\n"},{"id":"12987","messageId":"81b0412b0511300515u5d2840ccv92be6e374dd795be@mail.gmail.com","threadId":"2652","inReplyTo":"200511301405.19541.Josef.Weidendorfer@gmx.de","subject":"Re: Question about handling of heterogeneous repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-11-30T13:15:55Z","receivedAt":"2005-11-30T13:15:55Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:\n> > BTW, how does git-mv behave for out-of-tree renaming? How about\n> > inter-repo renaming (remove+add)?\n>\n> git-mv will fail. The source has to appear in git-ls-files, and the\n> target simply is given to \"git-update-index -add\", which will return an\n> 'outside repository' error. Hmmm... git-mv should check this itself.\n>\n> To detect inter-repository renaming, one has to see both repositories.\n> Currently, git/cogito etc. commands only work with one repository only.\n\nThis case is somewhat special: one is _guaranteed_ to see both repositories.\n\nPS: Im'restoring git@vger.kernel.org in cc-list, the discussion could be useful\n"},{"id":"297324","messageId":"Pine.LNX.4.63.0511301457040.2284@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2652","inReplyTo":"81b0412b0511300515u5d2840ccv92be6e374dd795be@mail.gmail.com","subject":"Re: Question about handling of heterogeneous repositories","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-30T13:58:11Z","receivedAt":"2005-11-30T13:58:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 30 Nov 2005, Alex Riesen wrote:\n\n> On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:\n> >\n> > To detect inter-repository renaming, one has to see both repositories. \n> > Currently, git/cogito etc. commands only work with one repository \n> > only.\n> \n> This case is somewhat special: one is _guaranteed_ to see both \n> repositories.\n\nIt is even more so: it is guaranteed that git cannot reconstruct this \nas a move operation.\n\nHth,\nDscho\n"},{"id":"12992","messageId":"200511301540.34776.Josef.Weidendorfer@gmx.de","threadId":"2652","inReplyTo":"Pine.LNX.4.63.0511301457040.2284@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Question about handling of heterogeneous repositories","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-30T14:40:34Z","receivedAt":"2005-11-30T14:40:34Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Wednesday 30 November 2005 14:58, Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 30 Nov 2005, Alex Riesen wrote:\n> \n> > On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:\n> > >\n> > > To detect inter-repository renaming, one has to see both repositories. \n> > > Currently, git/cogito etc. commands only work with one repository \n> > > only.\n> > \n> > This case is somewhat special: one is _guaranteed_ to see both \n> > repositories.\n> \n> It is even more so: it is guaranteed that git cannot reconstruct this \n> as a move operation.\n\nSay it in another way: because currently, git commands only work in the\nscope of one repository, there is no need to want to detect an\ninter-repository rename.\n\nGit has no explicit support for renaming, but can do it. Why should it\nbe a problem to write a tool which is able to detect inter-repository\nrenames? Still, such a search probably would be very expensive.\n\ngit-mv could support this. Additional to deleting from\none repository and adding to the new, it could generate a remark for\nthe commit message, like:\n\n Added file xxx is from remote repo '/path/myrepo' with name 'yyy'\n (file SHA1: 123445... from remote commit SHA1: 345667...)\n\nThis info could be interesting both for humans and a history browsing tool.\nThe tool still would have to know where to look for repo '/path/myrepo'.\nIt could also work for moving subdirectories (ie. trees instead of files).\n\nJosef\n"},{"id":"12990","messageId":"81b0412b0511300701w71da125am2dcc896b4693f37f@mail.gmail.com","threadId":"2652","inReplyTo":"200511301540.34776.Josef.Weidendorfer@gmx.de","subject":"Re: Question about handling of heterogeneous repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-11-30T15:01:00Z","receivedAt":"2005-11-30T15:01:00Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:\n> git-mv could support this. Additional to deleting from\n> one repository and adding to the new, it could generate a remark for\n> the commit message, like:\n>\n>  Added file xxx is from remote repo '/path/myrepo' with name 'yyy'\n>  (file SHA1: 123445... from remote commit SHA1: 345667...)\n\nThat's sounds very tempting to special-case for nested repos :)\n\nMaybe use .git/objects/info/alternates in top-level repo? It may\nhave side-effects of the new objects ending up in top-level repo\nif commited from top-level directory. Even then, the tools can\nbe tought to stop looking for GIT_DIR in the directory closest\nto the file being commited:\n  $ pwd\n  .../top\n  $ git-commit sub1/dir/file\n  ... uses repo in .../top/sub1 instead of $(pwd)/../top/.git\n\nLooks very messy, with a potential for lots of corner cases and\nnot that tempting anymore :(\n\n> This info could be interesting both for humans and a history browsing tool.\n> The tool still would have to know where to look for repo '/path/myrepo'.\n> It could also work for moving subdirectories (ie. trees instead of files).\n\nWell, these are just lots of files. I can't really think of case were\nI'd need to know about moving a directory without knowing what\nhappened to the files.\n\n>\n> Josef\n>\n"},{"id":"12997","messageId":"200511301749.18073.Josef.Weidendorfer@gmx.de","threadId":"2652","inReplyTo":"81b0412b0511300701w71da125am2dcc896b4693f37f@mail.gmail.com","subject":"Re: Question about handling of heterogeneous repositories","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-30T16:49:17Z","receivedAt":"2005-11-30T16:49:17Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Wednesday 30 November 2005 16:01, Alex Riesen wrote:\n> On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:\n> > git-mv could support this. Additional to deleting from\n> > one repository and adding to the new, it could generate a remark for\n> > the commit message, like:\n> >\n> >  Added file xxx is from remote repo '/path/myrepo' with name 'yyy'\n> >  (file SHA1: 123445... from remote commit SHA1: 345667...)\n> \n> That's sounds very tempting to special-case for nested repos :)\n\nIf the repo path is an URL, this works quite general. I tried\nto avoid adding local head names to this remark...\n\n> Maybe use .git/objects/info/alternates in top-level repo?\n\nOr better the .git/remotes namespace...\nStill, this is misusing repo-local config for multiple repos.\nSeems quite confusing for me.\n\n> It may \n> have side-effects of the new objects ending up in top-level repo\n> if commited from top-level directory. Even then, the tools can\n> be tought to stop looking for GIT_DIR in the directory closest\n> to the file being commited:\n>   $ pwd\n>   .../top\n>   $ git-commit sub1/dir/file\n>   ... uses repo in .../top/sub1 instead of $(pwd)/../top/.git\n> \n> Looks very messy, with a potential for lots of corner cases and\n> not that tempting anymore :(\n\ngit-mv would have to do exactly something like this to detect\ninter-repo renames at all ;-)\nBut in general, this is really messy.\n\nSee my suggestion in a previous thread with similar topic\n http://www.gelato.unsw.edu.au/archives/git/0511/12028.html\n\nJosef\n"},{"id":"13030","messageId":"81b0412b0512010016k202e3888ube5dae91c90cc5bb@mail.gmail.com","threadId":"2652","inReplyTo":"200511301749.18073.Josef.Weidendorfer@gmx.de","subject":"Re: Question about handling of heterogeneous repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-12-01T08:16:06Z","receivedAt":"2005-12-01T08:16:06Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:\n> git-mv would have to do exactly something like this to detect\n> inter-repo renames at all ;-)\n> But in general, this is really messy.\n\nThat's is what I'm most afraid of.\n\n> See my suggestion in a previous thread with similar topic\n>  http://www.gelato.unsw.edu.au/archives/git/0511/12028.html\n\nOh, thanks! Pity, I missed that discussion,\nPasky's subprojects is exactly what I am looking for.\n"}]}