Re: git-gui and gitk-git as submodules (Re: [RFC PATCH 0/2] Teach "git status" the "--ignore-submodules" option)

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jun 26, 2010, 11:45 UTC
Message-ID: <4C25E83E.4080905@web.de>
In-Reply-To: <AANLkTimqXhGw5fAAgZsoDAI9s6kaIzcka9mbFEW8j05v@mail.gmail.com>

Am 26.06.2010 06:44, schrieb Tay Ray Chuan:

Show 10 quoted lines

> On Sat, Jun 26, 2010 at 3:01 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Given a patch to automatically resolve submodule-ejection/subtree-merge
>> conflicts, do you think a patch series to split off gitk and git-gui
>> as submodules could live in pu eventually?
> 
> +1
> 
> They do sound like they'd fit into the submodule paradigm. Further,
> having git use it would be a good showcase of the submodule feature -
> or bug. :)

Yes, I think having them as a submodule makes lots of sense. But submodules are not there yet. Unless I overlooked something, the following issues must be resolved before having these two as a submodule, otherwise people will complain (and rightfully so!):

1) Switching branches, merging, rebasing and resetting in the
   superproject must result in a checkout of the matching submodule
   work tree (right now you always have to issue a "git submodule
   update" afterwards to get the submodules in sync).

2) On "git clone" the submodules must be cloned and checked out too
   (currently you have to do a "git submodule update --init" after
   cloning the superproject).

3) Switching between commits in the superproject where a directory
   is replaced by a submodule or vice versa doesn't work right now.
   Submodules should handle this situation, otherwise the commit
   putting gitk and git gui into submodules would become a barrier.

I am working on these issues, but that will take some time. But when they are solved, me too thinks that these two should become submodules.