From: Alex Riesen <hidden> Date: 2016-06-15 22:42:13
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 :)
Greetings,
Alex Riesen
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:13
Alex Riesen wrote:
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 :)
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.
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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:13
Andreas Ericsson, Tue, Nov 22, 2005 20:40:50 +0100:
quoted
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.
And than, do you have to announce a special procedure everyone's is to
execute after a clone so all subrepos are cloned? How do you handle
common configs and clone options in subrepos? It also would be nice to
have branches visible not only in in subrepos but in top-repo as well,
and the other way around.
I'm also wondering, what implications core/lib/.git/{config,remotes/,refs/}
under control in core/ can have?..
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 "/"?
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:13
Dear diary, on Wed, Nov 23, 2005 at 12:22:28AM CET, I got a letter
where Alex Riesen [off-list ref] said that...
Andreas Ericsson, Tue, Nov 22, 2005 20:40:50 +0100:
quoted
quoted
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 :)
This is something e.g. Cogito wants to support, but does not yet.
Patches welcome.
quoted
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.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:13
Petr Baudis, Sun, Nov 27, 2005 14:11:47 +0100:
quoted
quoted
quoted
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.
I wouldn't know what to patch, having no clear picture of the approach
myself, and especially when I don't feel safe using the solution. For
example, how do you go about moving/renaming files between subrepos?
Rename detection will not work, which will be unexpected...
BTW, how does git-mv behave for out-of-tree renaming? How about
inter-repo renaming (remove+add)?
quoted
quoted
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.
well, it ignored the ".git"s in the subdirs, not _the_ subdirectories.
I think that can be helped by putting the directories themselves into
.gitignore lists.