Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
Am 28.03.2014 18:10, schrieb W. Trevor King: On Fri, Mar 28, 2014 at 05:57:50PM +0100, Jens Lehmann wrote: Am 28.03.2014 04:58, schrieb W. Trevor King: On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote: No the remote branch is in the upstream subproject. I suppose I meant “the submodule's remote-tracking branch following the upstream subproject's HEAD which we just fetched so it's fairly current” ;). Hmm, maybe we should change the existing “upstream submodule” to “upstream subproject” for consistency? For me it's still an upstream submodule ... We have a few existing “[upstream] subproject” references though. I prefer subproject, because the submodule's upstream repository is likely a bare repo and not a submodule itself. It's also possible (likely?) that the upstream repository is a stand-alone project, and not designed to always be a submodule. However, “upstream submodule” and “submodule's upstream” are both clear enough, and if they're the consensus phrasing, I'd rather standardize on them than jump back and forth between phrasings in the docs. I can write up a patch that shifts us to consistently use one form, once we decide what that should be (although I'm happy to let someone else write the patch too ;). Apart from the RelNotes there are only seven places in the Documentation directory where the term subproject is used: - Two in git-submodule.txt (which are those you recently added in the series that introduced the regression and would be gone if we revert that) - One in git-write-tree.txt (but as I understand it the --prefix option can be used to record tree objects for other tools too, so the more generic term subproject looks OK to me there) - Four occurrences in user-manual.txt describing the diff format for submodules (which I assume will always stay [+-]Subproject for backwards compatibility reasons) If we do not revert your series I'll be happy to write up a patch replacing the two usages of subproject in git-submodule.txt ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
Am 28.03.2014 04:36, schrieb W. Trevor King:
gitmodule(5) mentioned 'master' as the default remote branch, but
folks using checkout-style updates are unlikely to care which upstream
branch their commit comes from (they only care that the clone fetches
that commit). If they haven't set submodule.name.branch, it makes
more sense to mirror 'git clone' and use the subproject's HEAD than to
default to 'master' (which may not even exist).
After the initial clone, subsequent updates may be local or remote.
Local updates (integrating gitlink changes) have no need to fetch a
specific remote branch, and get along just fine without
submodule.name.branch. Remote updates do need a remote branch, but
HEAD works as well here as it did for the initial clone.
Reported-by: Johan Herland jo...@herland.net
Signed-off-by: W. Trevor King wk...@tremily.us
---
This still needs tests, but it gets through the following fine:
rm -rf superproject subproject
mkdir subproject
(cd subproject
git init
echo 'Subproject' README
git add README
git commit -m 'Subproject commit'
git branch -m master next
)
mkdir superproject
(cd superproject
git init
git submodule add ../subproject submod
git commit -am 'Add submod'
)
(cd subproject
echo 'work work work' README
git commit -am 'Subproject commit 2'
)
(cd superproject
git submodule update --remote
git commit -am 'Add submod'
)
The main drawback to this approach is that we're changing a default,
but I agree with John's:
On Fri, Mar 28, 2014 at 12:21:23AM +0100, Johan Herland wrote:
I expect in most cases where origin/master happens to be the Right
Answer, using the submodule's upstream's HEAD will yield the same
result.
so the default-change may not be particularly intrusive.
I'd prefer a solution that doesn't change any defaults for the
checkout use case (again). Maybe it is a better route to revert
this series, then add tests describing the current behavior for
checkout submodules as a next step before adding the branch mode
for rebase and merge users again?
Cheers,
Trevor
Documentation/git-submodule.txt | 2 +-
Documentation/gitmodules.txt| 5 +++--
git-submodule.sh| 11 ---
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 46c1eeb..c485a17 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -284,7 +284,7 @@ OPTIONS
the superproject's recorded SHA-1 to update the submodule, use the
status of the submodule's remote-tracking branch. The remote used
is branch's remote (`branch.name.remote`), defaulting to `origin`.
- The remote branch used defaults to `master`, but the branch name may
+ The remote branch used defaults to `HEAD`, but the branch name may
be overridden by setting the `submodule.name.branch` option in
either `.gitmodules` or `.git/config` (with `.git/config` taking
precedence).
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index f539e3f..1aecce9 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -53,8 +53,9 @@ submodule.name.update::
submodule.name.branch::
A remote branch name for tracking updates in the upstream submodule.
- If the option is not specified, it defaults to 'master'. See the
- `--remote` documentation in linkgit:git-submodule[1] for details.
+ If the option is not specified, it defaults to the subproject's
+ HEAD. See the `--remote` documentation in linkgit:git-submodule[1]
+ for details.
+
This branch name is also used for the local branch created by
non-checkout cloning updates. See the `update` documentation in
diff --git a/git-submodule.sh b/git-submodule.sh
index 6135cfa..5f08e6c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -819,8 +819,8 @@ cmd_update()
name=$(module_name $sm_path) || exit
url=$(git config submodule.$name.url)
config_branch=$(get_submodule_config $name branch)
- branch=${config_branch:-master}
- local_branch=$branch
+ branch=${config_branch:-HEAD}
+ local_branch=$config_branch
if ! test -z $update
then
update_module=$update
@@ -860,7 +860,12 @@ Maybe you want to use 'update --init'?)
if ! test -d $sm_path/.git -o -f $sm_path/.git
then
- start_point=origin/${branch}
+ if test -n $config_branch
+ then
+ start_point=origin/$branch
+ else
+ start_point=
+ fi
module_clone $sm_path $name $url $reference
$depth
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
On Mon, Mar 31, 2014 at 09:35:07PM +0200, Jens Lehmann wrote: Am 28.03.2014 04:36, schrieb W. Trevor King: The main drawback to this approach is that we're changing a default, but I agree with John's: On Fri, Mar 28, 2014 at 12:21:23AM +0100, Johan Herland wrote: I expect in most cases where origin/master happens to be the Right Answer, using the submodule's upstream's HEAD will yield the same result. so the default-change may not be particularly intrusive. I'd prefer a solution that doesn't change any defaults for the checkout use case (again). Maybe it is a better route to revert this series, then add tests describing the current behavior for checkout submodules as a next step before adding the branch mode for rebase and merge users again? The change in defaults should only adversely effect users who: * don't configure submodule.name.branch, * use --remote updates, * expect them to pull the master branch of the submodule's upstream, and * have an upstream whose HEAD doesn't point at master. Since 23d25e4 (submodule: explicit local branch creation in module_clone, 2014-01-26), we adversely effects users (regardless of update strategy) who: * don't configure submodule.name.branch, and * update-clone from a submodule upstream that doesn't have a master branch. But with this patch we'll fix that. Before 23d25e4, we adversly affected users who: * used non-checkout update strategies, and * wanted an attached HEAD after update-clones. All of these were easy to work around, with either: $ git config submodule.$name.branch $branch or: $ cd $submod $ git checkout $branch I'm fine reverting 23d25e4 if we want to kick it around some more, but I have trouble imagining a future UI that works for both: * users that want --remote to pull master even though upstream's HEAD points elsewhere, and * users that want --remote to pull HEAD because upstream doesn't have a master branch, if neither of those users are willing to configure an explicit submodule.name.branch. Cheers, Trevor -- 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
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
Jens Lehmann jens.lehm...@web.de writes: I'd prefer a solution that doesn't change any defaults for the checkout use case (again). Maybe it is a better route to revert this series, then add tests describing the current behavior for checkout submodules as a next step before adding the branch mode for rebase and merge users again? Sounds like a good idea to revert the entire series, as that would give us longer to think the whole thing through. It would certainly avoid unexpected fallout in 2.0 where we already have other changes, all of which are known/designed to be backward incompatible with a set of carefully planned transition plans. This submodule change may have meant well, but does not seem to sit well together with these other changes. Perhaps in 2.1 or 2.2. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
Am 28.03.2014 04:58, schrieb W. Trevor King: On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote: On Thu, Mar 27, 2014 at 11:43:47PM -0400, Eric Sunshine wrote: On Thu, Mar 27, 2014 at 11:36 PM, W. Trevor King wk...@tremily.us wrote: submodule.name.branch:: A remote branch name for tracking updates in the upstream submodule. - If the option is not specified, it defaults to 'master'. See the - `--remote` documentation in linkgit:git-submodule[1] for details. + If the option is not specified, it defaults to the subproject's Did you mean s/subproject/submodule/ ? + HEAD. See the `--remote` documentation in linkgit:git-submodule[1] + for details. No the remote branch is in the upstream subproject. I suppose I meant “the submodule's remote-tracking branch following the upstream subproject's HEAD which we just fetched so it's fairly current” ;). Hmm, maybe we should change the existing “upstream submodule” to “upstream subproject” for consistency? For me it's still an upstream submodule ... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
On Fri, Mar 28, 2014 at 05:57:50PM +0100, Jens Lehmann wrote: Am 28.03.2014 04:58, schrieb W. Trevor King: On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote: No the remote branch is in the upstream subproject. I suppose I meant “the submodule's remote-tracking branch following the upstream subproject's HEAD which we just fetched so it's fairly current” ;). Hmm, maybe we should change the existing “upstream submodule” to “upstream subproject” for consistency? For me it's still an upstream submodule ... We have a few existing “[upstream] subproject” references though. I prefer subproject, because the submodule's upstream repository is likely a bare repo and not a submodule itself. It's also possible (likely?) that the upstream repository is a stand-alone project, and not designed to always be a submodule. However, “upstream submodule” and “submodule's upstream” are both clear enough, and if they're the consensus phrasing, I'd rather standardize on them than jump back and forth between phrasings in the docs. I can write up a patch that shifts us to consistently use one form, once we decide what that should be (although I'm happy to let someone else write the patch too ;). Cheers, Trevor -- 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
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
Jens Lehmann jens.lehm...@web.de writes: Am 28.03.2014 04:58, schrieb W. Trevor King: On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote: On Thu, Mar 27, 2014 at 11:43:47PM -0400, Eric Sunshine wrote: On Thu, Mar 27, 2014 at 11:36 PM, W. Trevor King wk...@tremily.us wrote: submodule.name.branch:: A remote branch name for tracking updates in the upstream submodule. - If the option is not specified, it defaults to 'master'. See the - `--remote` documentation in linkgit:git-submodule[1] for details. + If the option is not specified, it defaults to the subproject's Did you mean s/subproject/submodule/ ? + HEAD. See the `--remote` documentation in linkgit:git-submodule[1] + for details. No the remote branch is in the upstream subproject. I suppose I meant “the submodule's remote-tracking branch following the upstream subproject's HEAD which we just fetched so it's fairly current” ;). Hmm, maybe we should change the existing “upstream submodule” to “upstream subproject” for consistency? For me it's still an upstream submodule ... I inherited the habit of saying submodule vs superproject from Linus (I think) during the very early days, and there is no such thing as subproject or supermodule in my vocabulary. Just one documentation-reader's opinion, not an edict from the maintainer. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] submodule: change submodule.name.branch default from master to HEAD
gitmodule(5) mentioned 'master' as the default remote branch, but
folks using checkout-style updates are unlikely to care which upstream
branch their commit comes from (they only care that the clone fetches
that commit). If they haven't set submodule.name.branch, it makes
more sense to mirror 'git clone' and use the subproject's HEAD than to
default to 'master' (which may not even exist).
After the initial clone, subsequent updates may be local or remote.
Local updates (integrating gitlink changes) have no need to fetch a
specific remote branch, and get along just fine without
submodule.name.branch. Remote updates do need a remote branch, but
HEAD works as well here as it did for the initial clone.
Reported-by: Johan Herland jo...@herland.net
Signed-off-by: W. Trevor King wk...@tremily.us
---
This still needs tests, but it gets through the following fine:
rm -rf superproject subproject
mkdir subproject
(cd subproject
git init
echo 'Subproject' README
git add README
git commit -m 'Subproject commit'
git branch -m master next
)
mkdir superproject
(cd superproject
git init
git submodule add ../subproject submod
git commit -am 'Add submod'
)
(cd subproject
echo 'work work work' README
git commit -am 'Subproject commit 2'
)
(cd superproject
git submodule update --remote
git commit -am 'Add submod'
)
The main drawback to this approach is that we're changing a default,
but I agree with John's:
On Fri, Mar 28, 2014 at 12:21:23AM +0100, Johan Herland wrote:
I expect in most cases where origin/master happens to be the Right
Answer, using the submodule's upstream's HEAD will yield the same
result.
so the default-change may not be particularly intrusive.
Cheers,
Trevor
Documentation/git-submodule.txt | 2 +-
Documentation/gitmodules.txt| 5 +++--
git-submodule.sh| 11 ---
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 46c1eeb..c485a17 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -284,7 +284,7 @@ OPTIONS
the superproject's recorded SHA-1 to update the submodule, use the
status of the submodule's remote-tracking branch. The remote used
is branch's remote (`branch.name.remote`), defaulting to `origin`.
- The remote branch used defaults to `master`, but the branch name may
+ The remote branch used defaults to `HEAD`, but the branch name may
be overridden by setting the `submodule.name.branch` option in
either `.gitmodules` or `.git/config` (with `.git/config` taking
precedence).
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index f539e3f..1aecce9 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -53,8 +53,9 @@ submodule.name.update::
submodule.name.branch::
A remote branch name for tracking updates in the upstream submodule.
- If the option is not specified, it defaults to 'master'. See the
- `--remote` documentation in linkgit:git-submodule[1] for details.
+ If the option is not specified, it defaults to the subproject's
+ HEAD. See the `--remote` documentation in linkgit:git-submodule[1]
+ for details.
+
This branch name is also used for the local branch created by
non-checkout cloning updates. See the `update` documentation in
diff --git a/git-submodule.sh b/git-submodule.sh
index 6135cfa..5f08e6c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -819,8 +819,8 @@ cmd_update()
name=$(module_name $sm_path) || exit
url=$(git config submodule.$name.url)
config_branch=$(get_submodule_config $name branch)
- branch=${config_branch:-master}
- local_branch=$branch
+ branch=${config_branch:-HEAD}
+ local_branch=$config_branch
if ! test -z $update
then
update_module=$update
@@ -860,7 +860,12 @@ Maybe you want to use 'update --init'?)
if ! test -d $sm_path/.git -o -f $sm_path/.git
then
- start_point=origin/${branch}
+ if test -n $config_branch
+ then
+ start_point=origin/$branch
+ else
+ start_point=
+ fi
module_clone $sm_path $name $url $reference
$depth $start_point $local_branch || exit
cloned_modules=$cloned_modules;$name
subsha1=
--
1.9.1.352.gd393d14.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
On Thu, Mar 27, 2014 at 11:36 PM, W. Trevor King wk...@tremily.us wrote:
gitmodule(5) mentioned 'master' as the default remote branch, but
folks using checkout-style updates are unlikely to care which upstream
branch their commit comes from (they only care that the clone fetches
that commit). If they haven't set submodule.name.branch, it makes
more sense to mirror 'git clone' and use the subproject's HEAD than to
default to 'master' (which may not even exist).
After the initial clone, subsequent updates may be local or remote.
Local updates (integrating gitlink changes) have no need to fetch a
specific remote branch, and get along just fine without
submodule.name.branch. Remote updates do need a remote branch, but
HEAD works as well here as it did for the initial clone.
Reported-by: Johan Herland jo...@herland.net
Signed-off-by: W. Trevor King wk...@tremily.us
---
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 46c1eeb..c485a17 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -284,7 +284,7 @@ OPTIONS
the superproject's recorded SHA-1 to update the submodule, use the
status of the submodule's remote-tracking branch. The remote used
is branch's remote (`branch.name.remote`), defaulting to `origin`.
- The remote branch used defaults to `master`, but the branch name may
+ The remote branch used defaults to `HEAD`, but the branch name may
be overridden by setting the `submodule.name.branch` option in
either `.gitmodules` or `.git/config` (with `.git/config` taking
precedence).
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index f539e3f..1aecce9 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -53,8 +53,9 @@ submodule.name.update::
submodule.name.branch::
A remote branch name for tracking updates in the upstream submodule.
- If the option is not specified, it defaults to 'master'. See the
- `--remote` documentation in linkgit:git-submodule[1] for details.
+ If the option is not specified, it defaults to the subproject's
Did you mean s/subproject/submodule/ ?
+ HEAD. See the `--remote` documentation in linkgit:git-submodule[1]
+ for details.
+
This branch name is also used for the local branch created by
non-checkout cloning updates. See the `update` documentation in
diff --git a/git-submodule.sh b/git-submodule.sh
index 6135cfa..5f08e6c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -819,8 +819,8 @@ cmd_update()
name=$(module_name $sm_path) || exit
url=$(git config submodule.$name.url)
config_branch=$(get_submodule_config $name branch)
- branch=${config_branch:-master}
- local_branch=$branch
+ branch=${config_branch:-HEAD}
+ local_branch=$config_branch
if ! test -z $update
then
update_module=$update
@@ -860,7 +860,12 @@ Maybe you want to use 'update --init'?)
if ! test -d $sm_path/.git -o -f $sm_path/.git
then
- start_point=origin/${branch}
+ if test -n $config_branch
+ then
+ start_point=origin/$branch
+ else
+ start_point=
+ fi
module_clone $sm_path $name $url $reference
$depth $start_point $local_branch || exit
cloned_modules=$cloned_modules;$name
subsha1=
--
1.9.1.352.gd393d14.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
On Thu, Mar 27, 2014 at 11:43:47PM -0400, Eric Sunshine wrote: On Thu, Mar 27, 2014 at 11:36 PM, W. Trevor King wk...@tremily.us wrote: submodule.name.branch:: A remote branch name for tracking updates in the upstream submodule. - If the option is not specified, it defaults to 'master'. See the - `--remote` documentation in linkgit:git-submodule[1] for details. + If the option is not specified, it defaults to the subproject's Did you mean s/subproject/submodule/ ? + HEAD. See the `--remote` documentation in linkgit:git-submodule[1] + for details. No the remote branch is in the upstream subproject. I suppose I meant “the submodule's remote-tracking branch following the upstream subproject's HEAD which we just fetched so it's fairly current” ;). Cheers, Trevor -- 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
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote: On Thu, Mar 27, 2014 at 11:43:47PM -0400, Eric Sunshine wrote: On Thu, Mar 27, 2014 at 11:36 PM, W. Trevor King wk...@tremily.us wrote: submodule.name.branch:: A remote branch name for tracking updates in the upstream submodule. - If the option is not specified, it defaults to 'master'. See the - `--remote` documentation in linkgit:git-submodule[1] for details. + If the option is not specified, it defaults to the subproject's Did you mean s/subproject/submodule/ ? + HEAD. See the `--remote` documentation in linkgit:git-submodule[1] + for details. No the remote branch is in the upstream subproject. I suppose I meant “the submodule's remote-tracking branch following the upstream subproject's HEAD which we just fetched so it's fairly current” ;). Hmm, maybe we should change the existing “upstream submodule” to “upstream subproject” for consistency? Trevor -- 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
