> IOW the mail body should look like the output of format-patch, optionally > some comments between "--" and the diffstat. > > Write a patch for SubmittingPatches. I shall do that :) > > > 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. 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 > 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. Then when you initialize your submodules it will be unable to fetch the commit object, isn't it ? Since git-submodule clones origin/HEAD, the submodule state committed in the repository must be reachable from origin/HEAD. Or the third interesting state is not "the default branch of the upstream repository of the submodule", i.e. origin/HEAD, but the most-probably-interesting-branch, i.e. the branch configured in .git/config as being fetched for the current branch of the local submodule HEAD. That is the point of this patch. It make clear, *for all registered submodules*, what is the current relationship between the current submodule state committed in the repository and the current submodule HEAD. The "fetch" is there to take into account the fact that the submodule state may not yet be available locally. Best, -- Sylvain -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
