Just to close the loop on this thread, it did turn out to be a
permission problem in our case. It was difficult to track down because
it was only a problem on one server in the cluster. Each server had a
system git config file at /usr/local/etc/gitconfig. This was a symlink
pointing to a single com
On Tue, Aug 21, 2012 at 02:52:02PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Modulo the above "you might want to turn the call to warn() to
> > another helper that can be used from elsewhere", this patch looks
> > perfect to me.
>
> And that "modulo" is fairly simple if we wan
Junio C Hamano writes:
> Modulo the above "you might want to turn the call to warn() to
> another helper that can be used from elsewhere", this patch looks
> perfect to me.
And that "modulo" is fairly simple if we wanted to go that route.
attr.c| 2 +-
dir.c | 2 +-
git
On Tue, Aug 21, 2012 at 09:50:27AM -0700, Junio C Hamano wrote:
> > Subject: [PATCH] gitignore: report access errors of exclude files
> >
> > When we try to access gitignore files, we check for their
> > existence with a call to "access". We silently ignore
> > missing files. However, if a file is
Jeff King writes:
> On Tue, Aug 21, 2012 at 02:10:59AM -0400, Jeff King wrote:
>
>> I think that makes sense. Like this patch?
>>
>> -- >8 --
>> Subject: [PATCH] config: warn on inaccessible files
>>
>> Before reading a config file, we check "!access(path, R_OK)"
>> to make sure that the file e
Jeff King writes:
> You can get multiple warnings from this, as some programs read the
> config multiple times. I don't think it's really worth caring about, as
> you would want to fix such a misconfiguration quickly anyway.
I agree that we wouldn't care too much about the multiple warnings,
and
On Tue, Aug 21, 2012 at 02:22:19AM -0400, Jeff King wrote:
> And this might be a good follow-on:
>
> -- >8 --
> Subject: [PATCH] gitignore: report access errors of exclude files
And if we are going to do that, then we almost certainly want to do
this.
-- >8 --
Subject: [PATCH] attr: warn on ina
On Tue, Aug 21, 2012 at 02:22:19AM -0400, Jeff King wrote:
> And this might be a good follow-on:
>
> -- >8 --
> Subject: [PATCH] gitignore: report access errors of exclude files
...and it would probably help if I gave you the version that actually
compiled.
-- >8 --
Subject: [PATCH] gitignore:
On Tue, Aug 21, 2012 at 02:10:59AM -0400, Jeff King wrote:
> I think that makes sense. Like this patch?
>
> -- >8 --
> Subject: [PATCH] config: warn on inaccessible files
>
> Before reading a config file, we check "!access(path, R_OK)"
> to make sure that the file exists and is readable. If it's
On Mon, Aug 20, 2012 at 08:49:42PM -0700, Junio C Hamano wrote:
> > No, I do not think it was on purpose. And it would be very hard to do
> > so, anyway; config callbacks are not given any information about the
> > source of the config variable, and cannot distinguish between repo,
> > global, and
Jeff King writes:
> On Mon, Aug 20, 2012 at 06:22:26PM -0700, Junio C Hamano wrote:
>
>> Does anybody recall if this is something we did on purpose? After
>> eyeballing the callchain starting from cmd_receive_pack() down to
>> receive_pack_config(), nothing obvious jumps at me.
>
> No, I do not
Jay Soffian writes:
> On Mon, Aug 20, 2012 at 9:53 PM, Brandon Casey wrote:
>>git config --system -e
>>
>> Hopefully your editor exposes the path that it is editing even if you
>> don't have permission to modify it.
>
> GIT_EDITOR=echo git config --system -e
>
> works for me.
Clever ;-)
-
On Mon, Aug 20, 2012 at 9:53 PM, Brandon Casey wrote:
>git config --system -e
>
> Hopefully your editor exposes the path that it is editing even if you
> don't have permission to modify it.
GIT_EDITOR=echo git config --system -e
works for me.
j.
--
To unsubscribe from this list: send the
On Tue, Aug 21, 2012 at 6:52 AM, Junio C Hamano wrote:
> Sitaram Chamarty writes:
>
>> On Mon, Aug 20, 2012 at 10:35 PM, Junio C Hamano wrote:
>>> John Arthorne writes:
>>>
For all the details see this bugzilla, particularly comment #59 where we
finally narrowed this down:
h
On Mon, Aug 20, 2012 at 06:22:26PM -0700, Junio C Hamano wrote:
> > "git config --system receive.denynonfastforwards true" is not honored.
> > At all. (And I checked there was nothing overriding it).
> >
> > "--global" does work (is honored).
> >
> > Tested on 1.7.11
>
> Thanks, and interesting
On Mon, Aug 20, 2012 at 6:22 PM, Junio C Hamano wrote:
> Sitaram Chamarty writes:
>
>> On Mon, Aug 20, 2012 at 10:35 PM, Junio C Hamano wrote:
>>> John Arthorne writes:
>>>
For all the details see this bugzilla, particularly comment #59 where we
finally narrowed this down:
h
Sitaram Chamarty writes:
> On Mon, Aug 20, 2012 at 10:35 PM, Junio C Hamano wrote:
>> John Arthorne writes:
>>
>>> For all the details see this bugzilla, particularly comment #59 where we
>>> finally narrowed this down:
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=343150
>>
>> What doe
On Mon, Aug 20, 2012 at 10:35 PM, Junio C Hamano wrote:
> John Arthorne writes:
>
>> For all the details see this bugzilla, particularly comment #59 where we
>> finally narrowed this down:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=343150
>
> What does "at the system level" in your "does
John Arthorne writes:
> For all the details see this bugzilla, particularly comment #59 where we
> finally narrowed this down:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=343150
What does "at the system level" in your "does *not* work at the
system level." exactly mean?
A configuration va
At eclipse.org we wanted all git repositories to disallow non-fastforward
commits by default. So, we set receive.denyNonFastForwards=true as a system
configuration setting. However, this does not prevent a non-fastforward
force push. If we set the same configuration setting in the local repository
20 matches
Mail list logo
