Re: rfc - Changing the way gitk and git-gui are managed

On Thu, 2010-07-22 at 19:39 -0700, Junio C Hamano wrote:

...snip...

...snip...

I really like the idea of using submodules, though only so that they will almost certainly get the UI attention they deserve. Indeed, in my mind that attention is needed enough that this sort of switch shouldn't be made until it's been given for a while.

The problem is that, unlike so much of git, submodules make themselves known. They're loud, they're in the way, they require management to work. Case in point: "Switching from 1.7.2 to this tree will of course give you a tree without gitk and git-gui (nothing a simple "git submodule init/update" cannot fix)"

So already in order to build a working git again, someone needs to manually run some extra commands, which could potentially (but not necessarily) download a bunch of objects they already have. Basic operations like switching branches, get an extra (and easily overlooked) burden, to which there is sometimes no obvious solution Ouch.

I've always hated how clunky and non-transparent submodules are. There are some serious issues which would need to be worked out in order to make them more transparent (not the least of which is "to be transparent, where do you put the extra data, and when do you put it there / when do you remove it?". I do wish that these issues would get resolved, and it's hard to give them the attention they need because [I assume, like me] the people who don't like them simply avoid using submodules, as "just track everything" just sounds more like the git way.

Git is simple. It's easy to understand because of some simple assumptions and definitions. Submodules are less-simple. There are a lot of edge-cases and a lot of not-so-edge cases which need to be looked out for in order to make them sane. Handling the tricky-but-common cases by putting it on the user to always hand-hold the VCS is stupid and broken.

What do people really want which a move to submodules would get them?
  - Sub-Projects can obviously be developed separately (no need to clone
all of git in order to work on gitk, for example)
  - Merges that make more sense, since you don't need to pass special
"subtree" options, all you need to do is update the commit which gitk
points to. This ignores that merges across the submodule/subtree
boundary will not work, and similarly changes which span submodules have
no way of being blamed or sanely merged.

It certainly doesn't help that whenever I think about "how to fix submodules", the more I think about them, the less I think they make any sense at all. [rant deleted]

Put me down as: I've wanted to use submodules in the past, and I like the idea of using them in the future, but I've yet to be at the point where I wanted to use submodules "now".