Re: [PATCH v5 2/2] submodule: pass on http.extraheader config settings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 28, 2016 at 12:52 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>
>> So when going with that philosophy, the user might be missing
>> switches like
>>
>>     -c-for-this-repo-only core.worktree=... -c
>> submodule.worktree=align-relative-to-parent
>>
>> i.e. when shifting the responsibility to the user, we need to have
>> switches to pass options to the repository or a subset of submodules?
>
> I think that is an excellent illlustration of the issue by an
> example of what we shouldn't do ;-)

So rather have a white / black list?

Could we have a pre curated list with the list easily changed by the user?
So instead of screaming at the mailing list they can work around easily,
and eventually someone fixes the "stupid" default?

Maybe a user would want to do

    git config --global submodule-credentials-filter-white-list "host.*"

instead? (Naming intentionally bad)

>
> "git" is not always about submodules, so "-c-but-not-for-submodules"
> option does not belong to "git" wrapper.
>
> Users use "git -c" and hope to affect what happens in submodules,
> only because "git submodule" support is still immature and does not
> have options to do that.  You certainly smell a linkage between
> "pass options to a selected subset of submodules" and your recent
> "give labels to submodules so that they can be named with *group
> syntax" topic, no?

I thought about that for a split second, but no. I mean it in the
most general  way possible.

It doesn't even have to be a submodule related thing at all.

I can imagine that `git gc` could learn to walk nested repos
(not submodules, just repos on disk inside the work tree).
And for that use case we'd maybe want to have a setting
to pack the nested repos more aggressively than the toplevel repo.

(Not sure if there would be a use case or such a thing, but it is the
first I came up with)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]