On 10-07-23 11:10 AM, Jens Lehmann wrote:
Am 22.07.2010 21:41, schrieb Avery Pennarun:
I create an app named myapp on github:
git://github.com/apenwarr/myapp
It uses 17 different ruby gems, which I import as subprojects. I have
two choices:
[1] .gitmodules can use absolute paths to the original gem locations:
git://github.com/rubygems/gem[1..n]
[2] Or else I can fork them all and use relative paths in .gitmodules:
../gem[1..n]
translates to --> git://github.com/apenwarr/gem[1..n]
You forgot what we do as best practice at work:
[3] Fork the gem repos on github (or another server reachable by your
co-workers) and use those, so you don't have to change the URL
later:
git://github.com/apenwarrrubygems/gem[1..n]
Your problems go away, setup has to be done only once on project
start and not for every developer, you can use your own branchnames
and you have a staging repo from where you can push patches upstream
if necessary.
What's best practice for open source projects? I do this, but nobody
except my coworkers can push to my forks, so it's a huge rigamarole just
to get a fix into a submodule.
That is just one example. Another one is code shared between
different repos (think: libraries) where you want to make sure that
a bugfix in the library made in project A will make it to the shared
code repo and thus doesn't have to be fixed again by projects B to X.
This was one of the reasons we preferred submodules over subtrees
in our evaluation, because there is no incentive to push fixes inside
the subtree back to its own repo like there is when using submodules.
But you stated above that each project has its own fork of the library.
So there's no special incentive to push changes from the fork back to
its master repo.
It's very clear that git-submodule's current behaviour totally
mismatches the entire git philosophy. That's why it's so impossible
to make the git-submodule command usable.
That's very strong accusation.
Agreed... but that doesn't make it wrong :)
But calling a feature "impossible to make ... usable" is an
interesting thing to say about a feature lots of people are
using productively in their daily work, no? ;-)
In my experience, it's possible to make it usable if and only if:
1. you have a small team
2. all of whom are very comfortable with git
3. changes inside submodules are either infrequent or only happen in a
single direction
4. the project is not public/open source
I think #4 is the killer reason why submodules don't work. It works
fine if the submodule is fairly independent, but if you have a patch to
the submodule that was created for and in the context of the
superproject, things get really annoying really quickly.
Bryan
--
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