On 10-07-23 01:11 PM, Jens Lehmann wrote:
Am 23.07.2010 18:05, schrieb Bryan Larsen:
On 10-07-23 11:10 AM, Jens Lehmann wrote:
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.
When you are not working on your own, it is preferable to be able to
get changes upstream into a submodules repo to share them.
So if you can do that (either via push or patches sent by email or
whatever), then use it's URL directly (and then you have the incentive
that fixes get pushed, which is nice).
Or you can't, then use a fork reachable by the people you work with
(then you still can see all fixes made by your group in the forked
repo and can decide to push them upstream). Then pushing fixes back
to the original repo is a matter of courtesy, as it is with every
other work flow I know.
And I think that is just the same thing we all do with plain git
repos when working with others: If you can push, you use it directly
to clone from, if you can't, you fork it.
So basically you're saying: sometimes you can use a non-forked
repository, which has a whole bunch of disadvantages, but has the minor
advantage that you're "forced" to push your changes upstream.
Which I see as a disadvantage because that means you're pushing untested
changes.
Or else you use a forked repo, which is basically the same as using
git-subtree, except for a lot of additional admin hassle.
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.
What is the problem with the "forked repo" solution for #4?
Please tell me how I can set up a public project on github where project
A contains module X, so that Joe Average User can clone A, make a change
in the module X and send a simple pull request to get that change into
A. The change is one that's inappropriate to push upstream to X
without additional work, but is appropriate for A at this point in time.
Joe's a beginning git user.
That's actually a simple use case compared to others I've run into.
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