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

[Will Palmer <wmpalmer@gmail.com>]

On Thu, 2010-07-22 at 19:39 -0700, Junio C Hamano wrote:
> Somebody off-list suggested removing gitk and git-gui directories from my
> repository and I've been playing with the idea and kind of like the end
> result.
...snip...
> 
> I am wondering what people think.
...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".

-- 
-- Will