3 messages, 3 authors, 2016-06-15 · open the first message on its own page
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:55:22
"W. Trevor King" [off-list ref] writes:
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.
Hrm, doesn't it make the "float at the tip of a branch" mode useless, though?
From: Heiko Voigt <hidden>
Date: 2016-06-15 22:55:23
On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote:
"W. Trevor King" [off-list ref] writes:quoted
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.Hrm, doesn't it make the "float at the tip of a branch" mode useless, though?
How about having a branch config option and reusing our submodule.$name.update option for specifying whether the user wants to always float to the tip of the branch? 1. If submodule.$name.update is pull it would checkout the specified tip. 2. If submodule.$name.update is checkout or none it would do the usual thing and you need to specify --pull to get the tip. I am still a little bit undecided about an automatically crafted commit. At $dayjob we sometimes update submodules to their tip without any superproject changes just to make sure we use the newest version. Most of the time the commit messages are along the lines of "updated submodule x to master". On one hand Junio is right that the person updating to the newest submodule stuff has no clue what to write in this message. On the other hand someone might as well just use this functionality to get all the tips of all the submodules checked out. He then individually decides which changes to take by using add but will then still use a commit message like the one above. So currently I am more on the "have an automatically generated commit message" side. Its in a similar corner like merge commits, that are also generated, for me. We could have it as the default and a --no-commit option (like merge) for people that want to stage submodules individually. Cheers Heiko
From: Sascha Cunz <hidden>
Date: 2016-06-15 22:55:23
Am Freitag, 23. November 2012, 16:55:21 schrieb Heiko Voigt:
I am still a little bit undecided about an automatically crafted commit. At $dayjob we sometimes update submodules to their tip without any superproject changes just to make sure we use the newest version. Most of the time the commit messages are along the lines of "updated submodule x to master". On one hand Junio is right that the person updating to the newest submodule stuff has no clue what to write in this message.
I've been thinking about that for a while, when I started using submodules. In the end, I concluded, that what I really want to see in the commit message, is something similar to $(git shortlog $OLD_SHA1..$NEW_SHA1). I've scripted that and taught my CI-Server to do it automatically, if possible. So most of the time, I really don't want an "automatically crafted commit" whenever something causes the tip of a submodule to be at a new SHA1. Just my $.02, though. Sascha