On 01.10.14 13:14, Michael Haggerty wrote:
[]
Nice done, small comments inline
> diff --git a/lockfile.c b/lockfile.c
> index d27e61c..e046027 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -7,20 +7,29 @@
>
> static struct lock_file *volatile lock_file_list;
>
> -static void remove_lock_fi
On 2014-10-01 19.10, Junio C Hamano wrote:
> Hilco Wijbenga writes:
>
>> Perhaps I completely misunderstand the meaning of core.filemode but I
>> thought it determined whether Git cared about changes in file
>> properties?
>
> By setting it to "false", you tell Git that the filesystem you
> plac
Hi,
I've enabled EXPENSIVE and ran the git test suite under msysgit/git-win-sdk with
git version 2.1.0.9753.g360f311.dirty.
Now I have some failing tests in t0027-autocrlf.sh in the MINGW only section
which puzzle me.
The offending test sets are
diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto
Hi,
This series aims to add a method to filter previously set variables.
The patch series can be best described by the 3/5 log message
which I have pasted below verbatim.
"
Add a new config variable "unset.variable" which unsets previously set
variables. It affects `git_config()` and `git_config_
Helped-by: Matthieu Moy
Signed-off-by: Tanay Abhra
---
Documentation/config.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3b5b24a..7f36d35 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -23
Make git_config_with_options() to use a configset to feed values
in the callback function. This change gives us the power to filter
variables we feed to the callback using custom constraints.
A slight behaviour change, git_config_int() loses the ability to
print the file name of the invalid variab
Add a new config variable "unset.variable" which unsets previously set
variables. It affects `git_config()` and `git_config_get_*()` family
of functions. It removes the matching variables from the `configset`
which were added previously. Those matching variables which come after
the "unset.variable
Helped-by: Matthieu Moy
Signed-off-by: Tanay Abhra
---
t/t1300-repo-config.sh | 54 ++
1 file changed, 54 insertions(+)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index ce5ea01..f75c001 100755
--- a/t/t1300-repo-config.sh
+++ b/t
Move configset_iter() to an appropriate position where it
can be called by git_config_*() family without putting
a forward declaration for it.
Helped-by: Matthieu Moy
Signed-off-by: Tanay Abhra
---
config.c | 38 +++---
1 file changed, 19 insertions(+), 19 delet
On 2014-10-02 14.39, Thomas Braun wrote:
> Hi,
>
> I've enabled EXPENSIVE and ran the git test suite under msysgit/git-win-sdk
> with
> git version 2.1.0.9753.g360f311.dirty.
>
> Now I have some failing tests in t0027-autocrlf.sh in the MINGW only section
> which puzzle me.
>
> The offending t
I always though during fetch I have to specify a refspec and that a
sha1 would not be accepted as a ref. Firing some like 'git fetch
origin ' should be forbidden. But in fact I see that such a
fetch command succeeds if you already have that object in your local
repo.
My question: is it allowed to
Am 02.10.2014 um 15:42 schrieb Torsten Bögershausen:
> On 2014-10-02 14.39, Thomas Braun wrote:
>> Hi,
>>
>> I've enabled EXPENSIVE and ran the git test suite under msysgit/git-win-sdk
>> with
>> git version 2.1.0.9753.g360f311.dirty.
>>
>> Now I have some failing tests in t0027-autocrlf.sh in the
On Thu, Oct 2, 2014 at 9:57 AM, Christian Halstrick
wrote:
> I always though during fetch I have to specify a refspec and that a
> sha1 would not be accepted as a ref. Firing some like 'git fetch
> origin ' should be forbidden. But in fact I see that such a
> fetch command succeeds if you already
On Wed, Oct 01, 2014 at 06:15:46PM -0700, Jonathan Nieder wrote:
> 3) Warn when 'git config' is called with GIT_CONFIG set, explaining
> that support will eventually be removed and that callers should
> pass --file= instead.
>
> 4) Once we're confident there are no scripts in the wild r
On Thu, Oct 02, 2014 at 10:22:50AM -0400, Dan Johnson wrote:
> >> git show af00f4c39bcc8dc29ed8f59a47066d5993c279e4
> > fatal: bad object af00f4c39bcc8dc29ed8f59a47066d5993c279e4
> >> git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4
> > error: no such remote ref af00f4c39bcc8dc29ed8f59a47
Torsten Bögershausen writes:
> On 2014-10-01 19.10, Junio C Hamano wrote:
>> Hilco Wijbenga writes:
>>
>>> Perhaps I completely misunderstand the meaning of core.filemode but I
>>> thought it determined whether Git cared about changes in file
>>> properties?
>>
>> By setting it to "false", you
Jeff King wrote:
> But I think Christian is arguing that the client side should complain
> that $sha1 is not a remote ref, and therefore not something we can
> fetch. This used to be the behavior until 6e7b66e (fetch: fetch objects
> by their exact SHA-1 object names, 2013-01-29). The idea there
David Aguilar writes:
> On Tue, Sep 30, 2014 at 01:23:18PM -0700, Junio C Hamano wrote:
>> Here are the topics that have been cooking. Commits prefixed with
>> '-' are only in 'pu' (proposed updates) while commits prefixed with
>> '+' are in 'next'.
>>
>> * da/include-compat-util-first-in-c (20
Jonathan Nieder writes:
> Yep. One possibility would be to do something like the following (A):
>
> 1) advertise in the git-config(1) manpage that the GIT_CONFIG
> environment variable only affects the behavior of the 'git config'
> command
>
> 2) introduce an environment variable GIT_
Jonathan Nieder writes:
> From: Ronnie Sahlberg
> ...
> In resolving functions, refuse to resolve refs that don't pass the
> check-ref-format(1) check unless the new RESOLVE_REF_ALLOW_BAD_NAME
> flag is passed. Even with RESOLVE_REF_ALLOW_BAD_NAME, refuse to
> resolve refs that escape the refs/
Jonathan Nieder writes:
> diff --git a/refs.c b/refs.c
> index f124c2b..6820c93 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -801,14 +801,16 @@ static int names_conflict(const char *refname1, const
> char *refname2)
>
> struct name_conflict_cb {
> const char *refname;
> - const char *o
Tanay Abhra writes:
(just this point quick)
> 1> The name of the variable, I could not decide between "unset.variable"
> and "config.unset", or may be some other name would be more appropriate.
I'd prefer to see this as [config] something.
I wish we did the include as "[config] include = path/
Tanay Abhra writes:
> 2> It affects both the C git_config() calls and, git config shell
> invocations. Due to this some variables may be absent from the git config -l
> result which might confuse the user.
I am not sure what you mean by this. If you process variable
definitions as they come, an
Tanay Abhra writes:
> +test_expect_success 'document how unset.variable will behave in shell
> scripts' '
> + rm -f .git/config &&
> + cat >expect <<-\EOF &&
> + EOF
> + git config foo.bar boz1 &&
> + git config --add foo.bar boz2 &&
> + git config unset.variable foo.bar
On 10/3/2014 1:39 AM, Junio C Hamano wrote:
> Tanay Abhra writes:
>
>> +test_expect_success 'document how unset.variable will behave in shell
>> scripts' '
>> +rm -f .git/config &&
>> +cat >expect <<-\EOF &&
>> +EOF
>> +git config foo.bar boz1 &&
>> +git config --add foo.bar
Tanay Abhra writes:
> On 10/3/2014 1:39 AM, Junio C Hamano wrote:
>> Tanay Abhra writes:
>>
>>> +test_expect_success 'document how unset.variable will behave in shell
>>> scripts' '
>>> + rm -f .git/config &&
>>> + cat >expect <<-\EOF &&
>>> + EOF
>>> + git config foo.bar boz1 &&
>>> +
On 10/3/2014 1:53 AM, Junio C Hamano wrote:
> Tanay Abhra writes:
>
>> On 10/3/2014 1:39 AM, Junio C Hamano wrote:
>>> Tanay Abhra writes:
>>>
+test_expect_success 'document how unset.variable will behave in shell
scripts' '
+ rm -f .git/config &&
+ cat >expect <<-\EOF &
On Thu, Oct 02, 2014 at 12:29:14PM -0700, Junio C Hamano wrote:
> Tanay Abhra writes:
>
> (just this point quick)
>
> > 1> The name of the variable, I could not decide between "unset.variable"
> > and "config.unset", or may be some other name would be more appropriate.
>
> I'd prefer to see th
Tanay Abhra writes:
> I can think of two solutions, one leave it as it is and advertise it to be
> explicitly typed in the config files at the appropriate position or to change
> the behavior of unset.variable to unset all matching variables in that file,
> before and after. We could also change
[trimming Ccs]
This is an attempt at implementing the suggested safe-include config
feature. It mostly has the semantics Junio suggested in the parent
post, but it does not directly extend the current include directive;
instead, it uses a separate safe-include directive. This is done so
that if a
This adds a variant of the include directive, where only certain
config variables in the included files are honoured. The set of
honoured variables consists of those the user has mentioned in a
safe-include.whitelist directive, along with a small set of git.git
blessed ones.
This can, for example,
This adds a script for testing various aspects of the safe-include feature.
Signed-off-by: Rasmus Villemoes
---
t/t1309-config-safe-include.sh | 96 ++
1 file changed, 96 insertions(+)
create mode 100755 t/t1309-config-safe-include.sh
diff --git a/t/t130
Hi,
When working on a "new feature branch" that touches a lot of files I
tend to make commits that affect only single files, and for very small
changes. Since at this stage I'm experimentating a lot - trying out
ideas, etc. - the commits tend to grow a lot (could be 50-70
individual commits, each
On Thu, Oct 2, 2014 at 6:37 PM, Rasmus Villemoes
wrote:
> This adds a variant of the include directive, where only certain
> config variables in the included files are honoured. The set of
> honoured variables consists of those the user has mentioned in a
> safe-include.whitelist directive, along
On Thu, Oct 2, 2014 at 10:27 PM, Junio C Hamano wrote:
> On Thu, Oct 2, 2014 at 6:37 PM, Rasmus Villemoes
> wrote:
>> This adds a variant of the include directive, where only certain
>> config variables in the included files are honoured. The set of
>> honoured variables consists of those the us
35 matches
Mail list logo
