On Sat, Nov 17, 2012 at 04:04:42PM +0100, Heiko Voigt wrote: > > On Sat, Nov 10, 2012 at 01:44:37PM -0500, W. Trevor King wrote: > > > $ git submodule pull-branch > > > > I think "floating submodules" is a misleading name for this feature > > though, since the checkout SHA is explicitly specified. We're just > > making it more convenient to explicitly update the SHA. How about > > "tracking submodules"? > > Until now we have always called this workflow floating submodules. I > imaging since the submodule floats to the newest revision (whatever the > user chooses that to be) instead of staying at the recorded sha1. > > "tracking submodules" sounds strange to me since the term tracked in git > is mainly used in combination with exact recorded history (e.g. tracking > branch). Since it is about *not* checking out the recorded sha1 but > something that can change I think that could cause confusion. > > I think floating is a more unambiguous term and already known on the > list.
I had been getting the impression that floating submodules would automatically update without explicit user intervention. After re-reading your initial floating submodules post, it looks like we do match up after the mapping: Git Heiko Trevor --------- ----------------- ------------- update update --checkout update update update --pull So I'll go back to "floating" ;). On Sat, Nov 17, 2012 at 04:30:07PM +0100, Heiko Voigt wrote: > > > (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 am not sure if hiding changes to the recorded SHA1 from the user is > such a useful thing. In the first step I would like it if it was kept > simple and only the submodule update machinery learned to follow a > branch. If that results in local changes that should be shown. The user > is still in charge of recording the updated SHA1 in his commit. I understand what you're warning against here, or what it has to do with "git diff". > From what I have heard of projects using this: They usually still have > something that records the SHA1s on a regular basis. Thinking further, > why not record them in git? We could add an option to update which > creates such a commit. I think it's best to have users craft their own commit messages explaining why the branch was updated. That said, an auto-generated hint (a la "git merge") would probably be a useful extra feature. -- 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
Description: OpenPGP digital signature