Re: RFC: display dirty submodule working directory in git gui and gitk

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 4, 2010, 19:05 UTC
Message-ID: <7viqbhelmh.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B423633.6090603@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

Show 18 quoted lines

> Am 04.01.2010 18:51, schrieb Nguyen Thai Ngoc Duy:
>> Incidentally I was just drafting git-super.sh it see how far it goes.
>> The goal was to implement some cross-module operations over time. "git
>> super status", "git super commit" and others could be handy.
>
> Hm, i'm not sure if this will really help us. I would rather see "git
> status" and friends do the right thing for submodules too. Maybe this
> has to be configurable but i think the separate commands that one has
> to use for submodules now are part of the usability problems we are
> seeing.
>
> IMHO putting the functionality of "git submodule summary" into "git
> diff" was a step in the right direction. This thread is about adding a
> line to the diff output when diffing against the working directory and
> a submodule has a dirty working directory too. Then you can ask "git
> diff" and it tells you anything you need to know about the submodule
> before committing or checking out in the supermodule (And IMO later on
> "git status" should give us this information too).

Both will be valid approaches to work toward the same goal. A separate prototype implementation can be a way to easily figure out what the desired features are.

If "git super status" does turns out to be consistent with what "git status" is supposed to do, you can decide to fold that into the latter at that point. On the other hand, information people may want from "git super status" could be different from what people want "git status" from, in which case it might be better to either become a new option to "git status", or become a new subcommand to "git submodule".

You start the prototype by changing "git status" and later decide that the end result either needs to become an optional behaviour, or maybe even a separate command. Either way the end result will be the same---a good feature to help people is placed at the most logical place.

For the past 12 months, you and Johan Herland were the people who had more than one patches with substance to git-submodule.sh and I would really appreciate and at the same time want to encourage experimentation by people like you who are heavy users with need for a better submodule support.

Thanks.