Re: [PATCH] better git-submodule status output

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 6, 2008, 16:29 UTC
Message-ID: <alpine.DEB.1.00.0807061821340.7342@eeepc-johanness>
In-Reply-To: <20080706160758.GA23385@jhaampe.org>

Hi,

On Sun, 6 Jul 2008, Sylvain Joyeux wrote:

Show 7 quoted lines

> > > Which one is the commit message ;-)?
> > 
> > I think it is clear that Sylvain has not read 
> > Documentation/SubmittingPatches yet.
> 
> Sylvain *has* read SubmittingPatches but has not understood every detail 
> of this very long document.

Oh. But you should have already seen on this list that almost everybody puts the oneline as subject, the commit message as first part of the mail body, then a "--", optionally some personal stuff that should not go into the commit message, and then the diffstat and all the rest.

IOW the mail body should look like the output of format-patch, optionally some comments between "--" and the diffstat.

Write a patch for SubmittingPatches.

Show 8 quoted lines

> > If you could enlighten me on what is wrong ...
> 
> > > People who rely on working submodule support, do you have any 
> > > feedback on this patch?
> > 
> > Not yet.  Will test/comment when the spurious "fetch" is fixed.
>
> I thought that the only thing that 'fetch' does is update FETCH_HEAD.

Uhoh.  'fetch' fetches.  Which means it does not only update something.

> My problem is that doing the fetch is the only way to know what is the 
> status of the submodule w.r.t. the registered commit. If you have a 
> better way to get that information, I'm all ears :P

Are you sure that you understand the submodule thing enough to patch git-submodule?

There are three states that are interesting:

- the committed submodule state:

  You get this in the superproject by "git ls-tree HEAD -- <dir>"

- the local HEAD of the submodule:

  (cd "<dir>" && git rev-parse --verify HEAD)

- the HEAD of the default branch of the upstream repository of the 
  submodule:

  (cd "<dir>" && git ls-remote origin HEAD)

  NOTE: this does not have to do _anything_ with the submodule: you can 
  easily have two independent branches (see "html" and "next" in git.git), 
  and the submodule is free to be pinned to whatever commit is available
  in the upstream repository.

  It is even possible that it is pinned to a commit that is only reachable 
  from a tag, not from a branch.

Hth, Dscho