Hi Peff,
On Fri, 29 Apr 2016, Jeff King wrote:
> On Fri, Apr 29, 2016 at 02:48:44PM +0200, Johannes Schindelin wrote:
>
> > > If you know off-hand how to teach my vim to use your preferred indenting,
> > > I'll gladly just brow-beat it into submission.
> >
> > For the record, I think the defaul
On Thu, Apr 28, 2016 at 03:44:50PM -0700, Junio C Hamano wrote:
> > I do not think "fetch" should grow submodule-specific
> > options,...
>
> The updated "git fetch" needs to grow submodule-specific options to
> at least either enable or disable "recurse into submodules", and
> that is true even
On Fri, Apr 29, 2016 at 02:29:25PM +0200, Johannes Schindelin wrote:
> The more I think about it, I actually think that we do the user a *really*
> great disservice by filtering the CONFIG_DATA_ENVIRONMENT. If I call
>
> git -c ... $cmd
>
> and that configuration is *not* picked up, it is
On Fri, Apr 29, 2016 at 02:48:44PM +0200, Johannes Schindelin wrote:
> > If you know off-hand how to teach my vim to use your preferred indenting,
> > I'll gladly just brow-beat it into submission.
>
> For the record, I think the default in vim is to indent two tabs after an
> unclosed parenthesi
Hi Junio,
On Fri, 29 Apr 2016, Johannes Schindelin wrote:
> On Thu, 28 Apr 2016, Junio C Hamano wrote:
>
> > Johannes Schindelin writes:
> >
> > > - if (starts_with(var, "credential."))
> > > + if (starts_with(var, "credential.") ||
> > > + (starts_with(var, "http."
Hi Junio,
On Thu, 28 Apr 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > - if (starts_with(var, "credential."))
> > + if (starts_with(var, "credential.") ||
> > + (starts_with(var, "http.") &&
> > + ends_with(var, ".extraheader"))
Hi Peff,
On Thu, 28 Apr 2016, Jeff King wrote:
> On Thu, Apr 28, 2016 at 12:28:21PM -0700, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > It's definitely sufficient, it's just annoying if a user shows up
> > > every week and says "I want X.Y", and then somebody else shows up a
> > > w
Stefan Beller writes:
> 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 m
Jeff King writes:
> Keep in mind that submodule interactions may be triggered from other
> non-submodule commands. So "git fetch", for instance, may end up caring
> about whether you pass "http.*" or "credential.*" down to the
> submodules.
> I do not think "fetch" should grow submodule-specific
On Thu, Apr 28, 2016 at 02:08:43PM -0700, Stefan Beller wrote:
> > 1. Ones where we _know_ that the config is nonsense to pass along,
> > _and_ where a user might conceivably make use of the
> > just-the-top-level version of it (core.worktree
> > comes to mind, though of course th
On Thu, Apr 28, 2016 at 2:03 PM, Jeff King wrote:
> On Thu, Apr 28, 2016 at 12:52:03PM -0700, Junio C Hamano wrote:
>
>> "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 subm
On Thu, Apr 28, 2016 at 2:00 PM, Jeff King wrote:
> On Thu, Apr 28, 2016 at 12:28:21PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > It's definitely sufficient, it's just annoying if a user shows up every
>> > week and says "I want X.Y", and then somebody else shows up a week later
On Thu, Apr 28, 2016 at 12:52:03PM -0700, Junio C Hamano wrote:
> "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 i
On Thu, Apr 28, 2016 at 12:28:21PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > It's definitely sufficient, it's just annoying if a user shows up every
> > week and says "I want X.Y", and then somebody else shows up a week later
> > and says "I want X.Z".
> >
> > Are we serving any pur
On Thu, Apr 28, 2016 at 12:52 PM, Junio C Hamano wrote:
> Stefan Beller 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 resp
Junio C Hamano writes:
> 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
>
Stefan Beller 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
Johannes Schindelin writes:
> - if (starts_with(var, "credential."))
> + if (starts_with(var, "credential.") ||
> + (starts_with(var, "http.") &&
> + ends_with(var, ".extraheader")))
I know you are fond of indenting with HT without aligning things
On Thu, Apr 28, 2016 at 12:28 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> It's definitely sufficient, it's just annoying if a user shows up every
>> week and says "I want X.Y", and then somebody else shows up a week later
>> and says "I want X.Z".
>>
>> Are we serving any purpose in vettin
Jeff King writes:
> It's definitely sufficient, it's just annoying if a user shows up every
> week and says "I want X.Y", and then somebody else shows up a week later
> and says "I want X.Z".
>
> Are we serving any purpose in vetting each one (and if so, what)?
Personally I do not think we would
On Thu, Apr 28, 2016 at 12:06:56PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Thu, Apr 28, 2016 at 09:09:44AM -0700, Stefan Beller wrote:
> >
> >> > I think the key thing with a blacklist is somebody has to go to the work
> >> > to audit the existing keys.
> >>
> >> Would it be s
Jeff King writes:
> On Thu, Apr 28, 2016 at 09:09:44AM -0700, Stefan Beller wrote:
>
>> > I think the key thing with a blacklist is somebody has to go to the work
>> > to audit the existing keys.
>>
>> Would it be sufficient to wait until someone screams at the mailing list
>> for some key to be
On Thu, Apr 28, 2016 at 09:09:44AM -0700, Stefan Beller wrote:
> > I think the key thing with a blacklist is somebody has to go to the work
> > to audit the existing keys.
>
> Would it be sufficient to wait until someone screams at the mailing list
> for some key to be blacklisted? (I mean in the
On Thu, Apr 28, 2016 at 8:39 AM, Jeff King wrote:
> On Thu, Apr 28, 2016 at 08:37:10AM -0700, Jacob Keller wrote:
>
>> I think I prefer a blacklist approach, since it reduces the need for
>> future changes, since most cases will either not put config on the
>> environment or (based on feedback on
On Thu, Apr 28, 2016 at 08:37:10AM -0700, Jacob Keller wrote:
> I think I prefer a blacklist approach, since it reduces the need for
> future changes, since most cases will either not put config on the
> environment or (based on feedback on the mailing list and bug reports)
> the user will believe
On Thu, Apr 28, 2016 at 6:49 AM, Jeff King wrote:
> On Thu, Apr 28, 2016 at 02:19:37PM +0200, Johannes Schindelin wrote:
>
>> > Should we consider just white-listing all of "http.*"?
>> >
>> > That would help other cases which have come up, like:
>> >
>> > http://thread.gmane.org/gmane.comp.vers
On Thu, Apr 28, 2016 at 02:19:37PM +0200, Johannes Schindelin wrote:
> > Should we consider just white-listing all of "http.*"?
> >
> > That would help other cases which have come up, like:
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/264840
> >
> > which wants to turn off h
On Thu, Apr 28, 2016 at 02:19:37PM +0200, Johannes Schindelin wrote:
> > Should we consider just white-listing all of "http.*"?
> >
> > That would help other cases which have come up, like:
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/264840
> >
> > which wants to turn off h
Hi Peff,
Cc:ing Jacob, the author of the CONFIG_DATA_ENVIRONMENT sanitizing code.
On Thu, 28 Apr 2016, Jeff King wrote:
> On Thu, Apr 28, 2016 at 12:03:47PM +0200, Johannes Schindelin wrote:
>
> > diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> > index 3bd6883..b338f93
On Thu, Apr 28, 2016 at 12:03:47PM +0200, Johannes Schindelin wrote:
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> index 3bd6883..b338f93 100644
> --- a/builtin/submodule--helper.c
> +++ b/builtin/submodule--helper.c
> @@ -127,7 +127,9 @@ static int module_name(int arg
To support this developer's use case of allowing build agents token-based
access to private repositories, we introduced the http.extraheader
feature, allowing extra HTTP headers to be sent along with every HTTP
request.
This patch allows us to configure these extra HTTP headers for use with
`git s
31 matches
Mail list logo
