Re: [RFC] submodule: change submodule.<name>.branch default from master to HEAD

[Jens Lehmann <Jens.Lehmann@web.de>]

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 ;-)