On Sun, Nov 11, 2012 at 02:33:45AM -0800, Junio C Hamano wrote: > The change seems to think "branch" is the _only_ thing the user > might want to record per submodule upon "git submodule add". I felt that earlier floating/tracking submodule patches were biting off more than they could chew, so I was looking for a lightweight fix to make the tracking workflow easier. It seems like I ended up with something that is too lightweight ;). > On the other hand, if this were one small part of a series to define > the "tip following mode" where (at least) > > (1) "git submodule update [$path]" makes sure that the checkout of > the submodule at $path matches the commit at the tip of the > branch named by submodule.$name.branch in .gitmodules of the > superproject, instead of the commit that is recorded in the > index of the superproject; and As I mentioned earlier, I think $ git submodule update [$path] should keep its current “checkout the already-registered SHA” functionality, with $ git submodule update --pull [$path] pulling the tracked branch. I'll add a patch implementing this to v4. In order to avoid losing (or creating) local-only submodule commits, I'll probably bail (with an error) on non-fast-forward pulls. Can anyone else think of other safety concerns? This means that I'll probably drop Phil's $submodule_* export in v4, because the only explicit use we have for it is this branch tracking. I still think it is a useful idea, but it may not be useful enough to be worth the complexity. > (2) "git diff [$path]" and friends in the superproject compares the > HEAD of the checkout of the submodule at $path with the tip of > the branch named by submodule.$name.branch in .gitmodules of > the superproject, instead of the commit that is recorded in the > index of the superproject. > Hmm. “git diff” compares the working tree with the local HEAD (just a SHA for submodules), so I don't think it should care about the status of a remote branch. This sounds like you want something like: $ git submodule foreach 'git diff origin/$submodule_branch' Perhaps this is enough motivation for keeping $submodule_* exports? > and the option were called something like "--follow-branch=$branch", > … I'll replace -r/--record with --follow-branch in v4. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy