Re: Composing git repositories

Am 28.03.2013 10:16, schrieb Ramkumar Ramachandra:

Jens Lehmann wrote:

quoted

Unless you acknowledge that submodules are a different repo, you'll
always run into problems. I believe future enhancements will make
this less tedious, but in the end they will stay separate repos
(which is the whole point, you'd want to use a different approach
- e.g. subtree - if you want to put stuff from different upstreams
into a single repo without keeping the distinction where all that
came from).

I acknowledge that it's a different repository.  It's just that I
think that our current design has too many seams: why do you think
it's impossible to make it seamless?

git-subtree is not an answer to anything.  Dumping all the history
into one repository has its limited usecases, but it is no solution.

Guess what: submodules are the solution for a certain set of use
cases, and tools like subtree are a solution for another set of
use cases. There is no silver bullet.

quoted

What else than a commit object should that be??? Submodules are
there to have a different upstream for a part of your work tree,
and that means a commit in that repo is the only sane thing to
record in the superproject. A lot of thought has been put into
this, and it is definitely a good choice [1].

Linus argues that it shouldn't be a tree object, and I agree with
that.  I don't see an argument that says that the commit object is a
perfect fit (probably because it's not).

There was discussion about what to record in the index/commit of
the superproject in early submodule days (some time before I became
involved in Git, seems I currently cannot find a link to that). A
commit is the thing to record here because it *is* the perfect fit,
as some years of submodule experience show.

quoted

How? The "submodules suck, we should try a completely different
approach" thingy comes up from time to time, but so far nobody
could provide a viable alternative to what we currently do.

My argument is not "submodules suck; we should throw them out of the
window, and start from scratch" at all.  I'm merely questioning the
fundamental assumptions that submodules make, instead of proposing
that we work around everything in shell.  We don't have to be married
to the existing implementation of submodules and try to fix all the
problems in shell.

You cannot simply change the fundamental assumptions of submodules
and expect them to be the same thing afterwards. And it doesn't
matter at all if we "fix all the problems in shell" or in C-code,
we'll fix the remaining problems that are fixable in whatever part
of Git it makes sense. And I don't have the impression you have an
idea about what submodules are good at, where they can be improved
and what problems they'll probably never solve.

quoted

And apart from that, let's not forget we identified some valuable
improvements to submodules in this thread:
[...]
All of those are topics I like to see materialize, and you are
welcome to tackle them.

Allow me a few days to think about changing the fundamental building
blocks to make our shell hackery easier.

Please go ahead, but if your goal is "to make our shell hackery
easier" I'm not interested. I want to improve the user experience
of submodules and don't care much in what language we achieve that.
And I can't see anything fundamental being wrong with submodules but
strongly believe they are a perfect match for some very important
use cases (some of which I see happening at my $dayjob for some
years now), so I still don't see what you are trying to "fix" here.