"W. Trevor King" [off-list ref] writes:
On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote:
quoted
"W. Trevor King" [off-list ref] writes:
...
quoted
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.
I am not quite sure I agree. When the project says "Use the tip of
'bar' branch for the submodule 'foo'" at the top-level, does an
individual user who is not working on the submodule 'foo' but merely
is using it have any clue as to why the submodule's 'foo' branch
'foo' moved, or does he necessarily even care?
If he doesn't care, why is he updating the submodule gitlink?
He may not be updating the gitlink with "git add foo" at the
top-level superproject level. He is just using that submodule as
part of the larger whole as he is working on either the top-level or
some other submodule. And checkout of 'foo' is necessary in the
working tree for him to work in the larger context of the project,
and 'foo' is set to float at the tip of its 'bar' branch. And that
checkout results in a commit that is different from the commit the
gitlink suggests, perhaps because somebody worked in 'foo' submodule
and advanced the tip of branch 'bar'.
So:
- at the top-level superproject level, entry 'foo' in the HEAD tree
points at an older commit;
- 'foo/.git/HEAD' points at refs/heads/bar, which matches the
working tree of 'foo' and the index foo/.git/index..
I am not sure what should happen to the entry 'foo' in the index of
the top-level superproject after such a 'submodule floats at the
tip' checkout, but I imagine that it must match the contents of
foo/.git/HEAD's tree. Otherwise, "git diff" at the top-level would
report local changes.
When committing his work at the top-level, he will see that 'foo'
gitlink is updated in that commit; after all that combination is the
context in which his work was done.
Or are you envisioning that such a check-out will and should show a
local difference at the submodule 'foo' by leaving the index of the
top-level superproject unchanged, and the user should refrain from
using "git commit -a" to avoid having to describe the changes made
on the 'bar' branch in the meantime in his top-level commit? That
is certainly fine by me (I am no a heavy submodule user to begin
with), but I am not sure if that is useful and helpful to the
submodule users.
On Mon, Nov 19, 2012 at 09:39:34PM -0800, Junio C Hamano wrote:
"W. Trevor King" [off-list ref] writes:
quoted
On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote:
quoted
"W. Trevor King" [off-list ref] writes:
...
quoted
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.
I am not quite sure I agree. When the project says "Use the tip of
'bar' branch for the submodule 'foo'" at the top-level, does an
individual user who is not working on the submodule 'foo' but merely
is using it have any clue as to why the submodule's 'foo' branch
'foo' moved, or does he necessarily even care?
If he doesn't care, why is he updating the submodule gitlink?
He may not be updating the gitlink with "git add foo" at the
top-level superproject level. He is just using that submodule as
part of the larger whole as he is working on either the top-level or
some other submodule. And checkout of 'foo' is necessary in the
working tree for him to work in the larger context of the project,
and 'foo' is set to float at the tip of its 'bar' branch. And that
checkout results in a commit that is different from the commit the
gitlink suggests, perhaps because somebody worked in 'foo' submodule
and advanced the tip of branch 'bar'.
The superproject gitlink should only be updated after
$ git submodule update --pull
A plain
$ git submodule update
would still checkout the previously-recorded SHA, not the new upstream
tip. The uncaring user should skip the "--pull", and there will be no
superproject changes to worry about.
Or are you envisioning that such a check-out will and should show a
local difference at the submodule 'foo' by leaving the index of the
top-level superproject unchanged,
A plain "git submodule update" will, yes. And this will clobber any
changes that have happened in the submodule directory and its index
(because the user explicitly asked to checkout the
superproject-recorded SHA)
and the user should refrain from using "git commit -a" to avoid
having to describe the changes made on the 'bar' branch in the
meantime in his top-level commit?
What would "git commit -a" be picking up? Nothing in the superproject
has changed?
That is certainly fine by me (I am no a heavy submodule user to
begin with), but I am not sure if that is useful and helpful to the
submodule users.
The benefit is that Ævar's
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
becomes
$ git submodule update --pull
Still an explicit pull, but much easier to remember.
--
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
On Tue, Nov 20, 2012 at 07:19:12AM -0500, W. Trevor King wrote:
The benefit is that Ævar's
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
becomes
$ git submodule update --pull
There is an important question still unanswered here for me: How does
the submodule get the configuration what the local branch tracks on the
remote side?
Cheers Heiko