Am 01.04.2013 01:50, schrieb Phil Hord:
> On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
> <artagnon@xxxxxxxxx> wrote:
>> Jens Lehmann wrote:
>>> 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.
>>
>> That's the core of your argument: submodules already solve what it
>> was meant to, and we can't get it to solve a larger class of problems.
>> In other words, you're implying that it's impossible to build a tool
>> that will be able to compose git repositories in a way that solves a
>> very large class of problems. I don't see conclusive proof for this,
>> so I have to disagree.
>
> I think it is possible to solve larger classes of problems with
> submodules, but it is a harder problem than you seem to think. In any
> case I do not think you need to re-engineer submodules to improve
> them.
>
> Sumodules are good for preserving history. When properly managed,
> they answer the question git always answers, "Where was my code in the
> past?" I would like proper management to be easier, but I understand
> why it is difficult; and I see it getting easier.
Exactly.
> Some users also want submodules to handle other tasks, like "Import
> branch-tracked upstream changes (i.e. git pull origin master)." This
> too is useful, but it is a different problem than submodules'
> primarily try to solve. But they do already solve _part_ of that
> problem ("Show me how these modules are related"), so it seems a
> trivial thing to ask them also to handle the "floating branch" task.
> The trick is to handle this task in a way that does not break the task
> they are designed and used for already.
But I think we recently learned to support that use case with
submodules. I think there are two floating models:
- Tracked:
Follow a branch in the submodule and let git help you to advance
the submodule to the tip of that branch at certain times, but
still record a certain SHA-1 in the superproject to maintain
reproducibility. We support this since 1.8.2 (see 06b1abb5 by
Trevor).
- Untracked:
Some people just want "the newest" tip of a branch checked out in
the submodule and update that from time to time (I suspect this
is because they are used to SVN externals, which I believe work
that way). You throw away reproducibility, which I think is not
good and not the way I expect Git to work. But that use case is
achieved with a simple script and some config settings telling
Git to don't even look for changes in the submodule anymore, and
submodule infrastructure will set up everything for you after
cloning the superproject. You run your custom script from time
to time and have a truly floating submodule.
So to me it looks we support both floating models with current Git's
submodule infrastructure.
> Some other users want submodules to solve the problem of composition,
> like "Show me the combined log of all these submodules." (Replace
> "show log" with "diff", "merge", "bisect" or even "rebase" if you
> like.) I think this is where Jens is leaning when working to improve
> the user experience. But this direction does not require
> re-architecting the fundamentals of submodules.
Correct. The only major change needed for that was to move the .git
directories into the .git directory of the superproject to prepare
for recursive update. But that is done under the hood and didn't
touch the fundamentals of using gitlinks and .gitmodules, it is just
a change in the layout of the local clone.
--
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