Question about handling of heterogeneous repositories

> Hi,
> 
> it is sometimes the case that a project consists of parts which are
> unrelated to each other, and only thing in common between them is that
> they all are used in that particular project. For example a program
> uses some library and the developer(s) of that program would like to
> have the source of that library somewhere close. Well, for this simple
> example one could just use two repositories, laid close to each other
> in a directory, like project/lib and project/prog.
> Now, if I make the example a bit more complex and say, that the
> developers of the program are the developers in that project and
> change everything under project/ directory, including
> project/library/. They are also good people and ready to give the
> changes to the library upstream.
> 
> How do they achieve that, without sending project/ and project/program/?
> 
> For everyone who have an experience with ClearCase or Perforce (I'm
> sorry for mentioning it) it is what the "mappings" are often used for:
> a project is build together from different parts, which can be worked
> on separately.
> 
> I'm trying to introduce git at work, but have to prepare myself for
> possible questions first, and this is one of them :)
> 

> >it is sometimes the case that a project consists of parts which are
> >unrelated to each other, and only thing in common between them is that
> >they all are used in that particular project. For example a program
> >uses some library and the developer(s) of that program would like to
> >have the source of that library somewhere close. Well, for this simple
> >example one could just use two repositories, laid close to each other
> >in a directory, like project/lib and project/prog.
> >Now, if I make the example a bit more complex and say, that the
> >developers of the program are the developers in that project and
> >change everything under project/ directory, including
> >project/library/. They are also good people and ready to give the
> >changes to the library upstream.
> >
> >How do they achieve that, without sending project/ and project/program/?
> >
> >For everyone who have an experience with ClearCase or Perforce (I'm
> >sorry for mentioning it) it is what the "mappings" are often used for:
> >a project is build together from different parts, which can be worked
> >on separately.
> >
> >I'm trying to introduce git at work, but have to prepare myself for
> >possible questions first, and this is one of them :)
> >
> 
> We do like this;
> 
> core
> core/gui
> core/lib
> 
> $ cat .gitignore
> gui
> lib
> 
> This is also nice because it lets the gui maintainers have the gui as 
> the root with the core and lib parts as subdirectories. Everyone has 
> their own responsibility checked out at top-level with other pieces 
> below it. It's easy enough to script a pull of all repos so everyone's 
> up to sync and everybody's happy.

> Andreas Ericsson, Tue, Nov 22, 2005 20:40:50 +0100:
> > >it is sometimes the case that a project consists of parts which are
> > >unrelated to each other, and only thing in common between them is that
> > >they all are used in that particular project. For example a program
> > >uses some library and the developer(s) of that program would like to
> > >have the source of that library somewhere close. Well, for this simple
> > >example one could just use two repositories, laid close to each other
> > >in a directory, like project/lib and project/prog.
> > >Now, if I make the example a bit more complex and say, that the
> > >developers of the program are the developers in that project and
> > >change everything under project/ directory, including
> > >project/library/. They are also good people and ready to give the
> > >changes to the library upstream.
> > >
> > >How do they achieve that, without sending project/ and project/program/?
> > >
> > >For everyone who have an experience with ClearCase or Perforce (I'm
> > >sorry for mentioning it) it is what the "mappings" are often used for:
> > >a project is build together from different parts, which can be worked
> > >on separately.
> > >
> > >I'm trying to introduce git at work, but have to prepare myself for
> > >possible questions first, and this is one of them :)

> > It would certainly be nicer to have git ignore directories that have the 
> > ".git" directory (so long as it's not the top of the repo, that is), but 
> > I haven't had the energy to fix that when there's already a solution 
> > that's simple enough and quite adequate.
> 
> BTW, will something like "*/.git/*" in info/exclude work? IOW, does *
> match a "/"?

> > > >For everyone who have an experience with ClearCase or Perforce (I'm
> > > >sorry for mentioning it) it is what the "mappings" are often used for:
> > > >a project is build together from different parts, which can be worked
> > > >on separately.
> > > >
> > > >I'm trying to introduce git at work, but have to prepare myself for
> > > >possible questions first, and this is one of them :)
> 
> This is something e.g. Cogito wants to support, but does not yet.
> Patches welcome.

> > > It would certainly be nicer to have git ignore directories that have the 
> > > ".git" directory (so long as it's not the top of the repo, that is), but 
> > > I haven't had the energy to fix that when there's already a solution 
> > > that's simple enough and quite adequate.
> > 
> > BTW, will something like "*/.git/*" in info/exclude work? IOW, does *
> > match a "/"?
> 
> Nope, but try just '.git' - in case it is not a pathname but just a
> filename (or dirname, for that matter), it will recursively apply to all
> the subtrees.

> > BTW, how does git-mv behave for out-of-tree renaming? How about
> > inter-repo renaming (remove+add)?
>
> git-mv will fail. The source has to appear in git-ls-files, and the
> target simply is given to "git-update-index -add", which will return an
> 'outside repository' error. Hmmm... git-mv should check this itself.
>
> To detect inter-repository renaming, one has to see both repositories.
> Currently, git/cogito etc. commands only work with one repository only.

> On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> >
> > To detect inter-repository renaming, one has to see both repositories. 
> > Currently, git/cogito etc. commands only work with one repository 
> > only.
> 
> This case is somewhat special: one is _guaranteed_ to see both 
> repositories.

> Hi,
> 
> On Wed, 30 Nov 2005, Alex Riesen wrote:
> 
> > On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > >
> > > To detect inter-repository renaming, one has to see both repositories. 
> > > Currently, git/cogito etc. commands only work with one repository 
> > > only.
> > 
> > This case is somewhat special: one is _guaranteed_ to see both 
> > repositories.
> 
> It is even more so: it is guaranteed that git cannot reconstruct this 
> as a move operation.

> git-mv could support this. Additional to deleting from
> one repository and adding to the new, it could generate a remark for
> the commit message, like:
>
>  Added file xxx is from remote repo '/path/myrepo' with name 'yyy'
>  (file SHA1: 123445... from remote commit SHA1: 345667...)

> On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > git-mv could support this. Additional to deleting from
> > one repository and adding to the new, it could generate a remark for
> > the commit message, like:
> >
> >  Added file xxx is from remote repo '/path/myrepo' with name 'yyy'
> >  (file SHA1: 123445... from remote commit SHA1: 345667...)
> 
> That's sounds very tempting to special-case for nested repos :)

> It may 
> have side-effects of the new objects ending up in top-level repo
> if commited from top-level directory. Even then, the tools can
> be tought to stop looking for GIT_DIR in the directory closest
> to the file being commited:
>   $ pwd
>   .../top
>   $ git-commit sub1/dir/file
>   ... uses repo in .../top/sub1 instead of $(pwd)/../top/.git
> 
> Looks very messy, with a potential for lots of corner cases and
> not that tempting anymore :(