Thanks for the mail archives! They were a very good read.
The smaller projects I have are fairly independent, so there isn't a
situation where a commit works well with the other commits. I just
wanted some ways to split each project out to its own repo. So that when
I want to do some git operations on one project, I don't have to worry
about the other projects. While submodules isn't an ideal solution, it
seems to be the closest. Maybe what I need from submodules is a way for
the super-repo to not record the commit of the sub-repos. i.e. Just use
the head of a branch. But if that's the case, maybe it's out of the
scope of a SCM, since I'm not really tracking a history anymore.
I haven't tried it yet, but the mr tool you mentioned seems interesting
too. I'll check it out.
Thanks!
Andrew
On 11-04-17 2:48 AM, Jonathan Nieder wrote:
Hi,
Jonathan Nieder wrote:
Yep, if you want to keep track of the state of a bunch of repos over
time, submodules are not so bad[*].
A kind person pointed out that I left out a footnote. I think all I
had been planning to say is that, roughly speaking, submodules are
about[1] saying that a specific commit is known to work well with the
rest of the code. A supermodule like the one discussed in [2] is only
likely to be useful if you are interested in what historical
combinations of repositories were published and meant to work well
together.
Ciao,
Jonathan
[1] e.g., http://thread.gmane.org/gmane.comp.version-control.git/27803/focus=27830
[2] http://lists.x.org/archives/xorg-devel/2009-September/001966.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html