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
signature.asc
Description: OpenPGP digital signature
