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
On 2014-10-01 19.10, Junio C Hamano wrote:
Hilco Wijbenga hilco.wijbe...@gmail.com 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
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
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
Helped-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
Documentation/config.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3b5b24a..7f36d35 100644
---
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
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 matthieu@imag.fr
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
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
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 matthieu@imag.fr
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
config.c | 38 +++---
1
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 test sets
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 sha1' 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
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 MINGW only
On Thu, Oct 2, 2014 at 9:57 AM, Christian Halstrick
christian.halstr...@gmail.com 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 sha1' should be forbidden. But in fact I see that such a
fetch
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
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
Torsten Bögershausen tbo...@web.de writes:
On 2014-10-01 19.10, Junio C Hamano wrote:
Hilco Wijbenga hilco.wijbe...@gmail.com writes:
Perhaps I completely misunderstand the meaning of core.filemode but I
thought it determined whether Git cared about changes in file
properties?
By
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 is
David Aguilar dav...@gmail.com 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'.
*
Jonathan Nieder jrnie...@gmail.com 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
Jonathan Nieder jrnie...@gmail.com writes:
From: Ronnie Sahlberg sahlb...@google.com
...
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
Jonathan Nieder jrnie...@gmail.com 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;
-
Tanay Abhra tanay...@gmail.com 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]
Tanay Abhra tanay...@gmail.com 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
Tanay Abhra tanay...@gmail.com 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 tanay...@gmail.com 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
Tanay Abhra tanay...@gmail.com writes:
On 10/3/2014 1:39 AM, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com 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 tanay...@gmail.com writes:
On 10/3/2014 1:39 AM, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com writes:
+test_expect_success 'document how unset.variable will behave in shell
scripts' '
+ rm -f .git/config
+ cat expect
On Thu, Oct 02, 2014 at 12:29:14PM -0700, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com 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
Tanay Abhra tanay...@gmail.com 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
[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
This adds a script for testing various aspects of the safe-include feature.
Signed-off-by: Rasmus Villemoes r...@rasmusvillemoes.dk
---
t/t1309-config-safe-include.sh | 96 ++
1 file changed, 96 insertions(+)
create mode 100755
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 r...@rasmusvillemoes.dk
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
On Thu, Oct 2, 2014 at 10:27 PM, Junio C Hamano gits...@pobox.com wrote:
On Thu, Oct 2, 2014 at 6:37 PM, Rasmus Villemoes r...@rasmusvillemoes.dk
wrote:
This adds a variant of the include directive, where only certain
config variables in the included files are honoured. The set of
honoured
35 matches
Mail list logo
