On Fri, Nov 09, 2012 at 05:29:27PM +0100, Heiko Voigt wrote:
I think we should agree on a behavior for this option and implement it
the same time when add learns about it. When we were discussing floating
submodules as an important option for the gerrit people I already started
to implement a proof of concept. Please have a look here:
https://github.com/hvoigt/git/commits/hv/floating_submodules
After skimming through this, something like
$ git submodule update --pull
would probably be better than introducing a new command:
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"?
--
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
Hi,
sorry for the late reply but my git time is limited.
On Sat, Nov 10, 2012 at 02:02:32PM -0500, W. Trevor King wrote:
On Fri, Nov 09, 2012 at 05:29:27PM +0100, Heiko Voigt wrote:
quoted
I think we should agree on a behavior for this option and implement it
the same time when add learns about it. When we were discussing floating
submodules as an important option for the gerrit people I already started
to implement a proof of concept. Please have a look here:
https://github.com/hvoigt/git/commits/hv/floating_submodules
After skimming through this, something like
$ git submodule update --pull
would probably be better than introducing a new command:
Yeah along the lines of that, but one thing to keep in mind:
We already have --rebase and --merge which do slightly different things
(I think). Adding --pull here should behave similar to them. Like fetch
and merge is the same to pull without submodules.
If I am understanding your goal correctly your --pull would be
different. On the other hand: A --pull makes no sense if we apply it to
the existing --merge option since it merges the recorded sha1 into the
current HEAD. Just a fetch would not really make a difference.
Thinking along the existing options I would probably still expect --pull
to merge something into the current HEAD. So maybe we have to iron out
where this command/option should go. But changing that once we have a
patch to discuss should not be that much work. So please proceed with
--pull and once we know exactly what it does we can polish that.
On Sat, Nov 10, 2012 at 01:44:37PM -0500, W. Trevor King wrote:
quoted
$ 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.
Cheers Heiko