Ramkumar Ramachandra wrote:
> The purpose of this series is to convince you that we've made a lot of
> fundamental mistakes while designing submodules, and that we should
> fix them now. [1/7] argues for a new object type, and this is the
> core of the idea.
Shouldn't it be possible to explain the same thing using a test
script illustrating intended UI?
> $ git clone gh:artagnon/varlog
> $ cd varlog
> $ git clone gh:artagnon/clayoven
> # Notice how it puts clayoven.git in ~/bare
I really would like to be able to continue doing something like
git clone --recurse-submodules git://repo.or.cz/cgit.git
# never mind!
rm -fr cgit
without leaving any clutter behind. I have used systems that kept
state in my home directory before and found them a pain in the neck to
debug. Others may disagree, though.
> # Again, just works! No cd-to-toplevel nonsense
Didn't Jens mention that git-submodule requiring that one work
at the toplevel is just a (presumably easily fixable) bug?
> If you think this is all a big waste of time, and that we should focus
> on improving git-submodule.sh, you're probably deranged. Because it's
I don't think that *you* should focus on improving git-submodule, as
long as you are not using it and dislike its design. But I do think
it's strange to at the same time
1) tell me I'm deranged for liking submodules
2) dismiss other experiments that have been created as alternatives
I like experimentation, which means sometimes having tools whose
purposes overlap, and I like when it's possible to help something
evolve to be better, even far enough to interoperate with or replace
uses of another tool.
I also believe in "live and let live". That means that even if
someone is a little crazy, if they are not actively harmful, I do not
destroy their tools.
That probably marks me as deranged.
Hope that helps,
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html