Re: [PATCH] better git-submodule status output

["Avery Pennarun" <apenwarr@gmail.com>]

On 7/7/08, Sylvain Joyeux <sylvain.joyeux@dfki.de> wrote:
> Yes, it fetches objects (admittedly, it updates something on the current
>  partition), but AFAIK does not change the state of the repository. So I thought
>  that it could be considered as a no-op from the repo point of view. The idea
>  behind the 'fetch' thing was to get the latest objects from the repository,
>  therefore being able to know the relationship between the currently committed
>  submodule state

I haven't looked at your patch, so I don't know if you're calling
fetch in such a way that it doesn't update any refs.  Anyway, fetching
is definitely not a no-op as far as the user is concerned.  For
example, if I'm on my laptop outside my company's LAN and I try to
fetch, it might take 30+ seconds for fetch to time out waiting for our
server.  So it's not okay to fetch unless I specifically ask for a
fetch.

The trick here, I think, is that there's only one time the submodule
should be linked to a commit you don't actually have.  It should only
happen if your parent module (supermodule) has been updated, but you
haven't recently done a fetch in the submodule.  Thus, I'd say the
best fix would be to find a way to have "git pull" or "git fetch" in
the supermodule also do a fetch in the submodule.  I think it's fair
to expect "fetchy" operations like fetch and pull to perhaps do some
extra fetches, but not fair to expect "status" to do extra work like
that.

Also note that "your supermodule links to a commit that you haven't
fetched yet" is a perfectly okay state to report to the user.  I might
use a "?" or something to indicate that.

Have fun,

Avery