Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases
I set up a git alias like this: git config --global alias.popmerge '!git stash pop git merge master' Then I call it, like this: git popmerge The git stash pop is executed, but the git merge master is ignored. If I run git merge master right after the git popmerge... it sumply runs as expected, performing the merge. I have other aliases with long sequences of commands... and they run flawlessly. It seems something at git stash pop makes the alias process to halt... Is it possible to avoid this behavior? How? Thanks. code 128 http://www.keepdynamic.com/barcoding/asp-net-barcode-generator.shtml -- View this message in context: http://git.661346.n2.nabble.com/RFC-PATCH-avoid-SIGPIPE-warnings-for-aliases-tp7574160p7615524.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFH 0/3] stable priority-queue
On Mon, Jul 14, 2014 at 01:02:56PM +0200, David Kastrup wrote: Jeff King p...@peff.net writes: As Junio and I discussed earlier in [1], this series makes the prio_queue struct stable with respect to object insertion (which in turn means we can use it to replace commit_list in more places). I don't think that this makes sense in general since it assumes the appropriate fallback behavior to be FIFO. Depending on the use case, it might be the other way round, or something else (like topology-based) entirely. Remember that this is just a tie-breaker for the regular comparison function. If you want to represent some other ordering, you are free to do the tie-breaking yourself in your comparison function. The one thing we can easily provide but do not is LIFO ordering for the tie-breaker. That would be trivial to add as a flag on the prio_queue, but I'd wait until there is actually a caller who wants it. Yes, it's a bit hacky to provide it for cases which _don't_ care about order (or implement their own separate tie-breaker). But the worst case there is that we are wasting some memory, and I wasn't able to measure a real slow-down. I think it's a reasonable compromise given the lack of generics in C. But if you have a case that is measurably affected, please let me know, and I can look into implementing it in a type-agnostic way (so that the embedded insertion counter becomes just another type). I see that struct commit already contains an integer field called index, assigned sequentially, which might conceivably be used for tie-breaking independent from the actual prio_queue use at no extra cost. I don't think it's a good idea to rely on that index, as it is anything but stable. It represents whatever order commits happened to be first touched in the current program run. So: 1. Performing the same operation in-process versus in a sub-process may produce different results. 2. Arguments to a command may have unexpected effects. E.g., specifying --tags to rev-list will look up the commit at each tag ref, giving them much lower index numbers than they would if we reached only through the normal traversal. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: a more helpful message on git status output
Junio C Hamano gits...@pobox.com writes: Julián Landerreche mani...@gmail.com writes: OK, I'm mostly convinced. A more verbose, educational output could read: (use git pull to fetch newer commits from upstream and update your local branch) (use git merge to update your local branch) I actually do not like that, to be honest. These brief reminders should be just that, and if anything, we should aim to make them shorter and more concise, not longer and more verbose. I think so too. For someone not willing to read the doc, the current message is sufficient, and for someone willing to read it, the output of git status is IHMO not a good place to teach the difference between merge and pull. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Ihre Hilfe,bitte !
Ihre Hilfe,bitte ! Ich bin frau Victoria Baker und bin ca 56 jahre alt und leide von krebs Meine Erbschaft ist usd8,9millionen Die Herkunft/ Von meinem verstorbenen Ehemann. Ich moechte meine Erbschaft durch Ihre Hilfe in Ihrem Land investieren. Meine investitionswuensche sind in der Energiesektor wenn sie mir helfen koennen. ich werde Ihnen mehr Einzelheiten schicken wenn Sie dabei helfen koennen Mit freundlichen Gruessen Frau Victoria Baker -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/6] branch.c: replace `git_config()` with `git_config_get_string()`
Use `git_config_get_string()` instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
branch.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/branch.c b/branch.c
index 46e8aa8..827307f 100644
--- a/branch.c
+++ b/branch.c
@@ -140,33 +140,17 @@ static int setup_tracking(const char *new_ref, const char
*orig_ref,
return 0;
}
-struct branch_desc_cb {
- const char *config_name;
- const char *value;
-};
-
-static int read_branch_desc_cb(const char *var, const char *value, void *cb)
-{
- struct branch_desc_cb *desc = cb;
- if (strcmp(desc-config_name, var))
- return 0;
- free((char *)desc-value);
- return git_config_string(desc-value, var, value);
-}
-
int read_branch_desc(struct strbuf *buf, const char *branch_name)
{
- struct branch_desc_cb cb;
+ const char *v = NULL;
struct strbuf name = STRBUF_INIT;
strbuf_addf(name, branch.%s.description, branch_name);
- cb.config_name = name.buf;
- cb.value = NULL;
- if (git_config(read_branch_desc_cb, cb) 0) {
+ if (git_config_get_string(name.buf, v)) {
strbuf_release(name);
return -1;
}
- if (cb.value)
- strbuf_addstr(buf, cb.value);
+ strbuf_addstr(buf, v);
+ free((char*)v);
strbuf_release(name);
return 0;
}
--
1.9.0.GIT
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/6] notes-util.c: replace `git_config()` with `git_config_get_value()`
Use `git_config_get_value()` instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
The function now raises an error instead of dying when a NULL value is found
for key notes.rewritemode.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
notes-utils.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/notes-utils.c b/notes-utils.c
index b64dc1b..ffa2b70 100644
--- a/notes-utils.c
+++ b/notes-utils.c
@@ -69,22 +69,24 @@ static combine_notes_fn parse_combine_notes_fn(const char
*v)
return NULL;
}
-static int notes_rewrite_config(const char *k, const char *v, void *cb)
+static void notes_rewrite_config(struct notes_rewrite_cfg *c)
{
- struct notes_rewrite_cfg *c = cb;
- if (starts_with(k, notes.rewrite.) !strcmp(k+14, c-cmd)) {
- c-enabled = git_config_bool(k, v);
- return 0;
- } else if (!c-mode_from_env !strcmp(k, notes.rewritemode)) {
+ const char *v;
+ struct strbuf key = STRBUF_INIT;
+ strbuf_addf(key, notes.rewrite.%s, c-cmd);
+ git_config_get_bool(key.buf, c-enabled);
+ strbuf_release(key);
+
+ if (!c-mode_from_env !git_config_get_value(notes.rewritemode,
v)) {
if (!v)
- return config_error_nonbool(k);
- c-combine = parse_combine_notes_fn(v);
- if (!c-combine) {
- error(_(Bad notes.rewriteMode value: '%s'), v);
- return 1;
+ config_error_nonbool(notes.rewritemode);
+ else {
+ c-combine = parse_combine_notes_fn(v);
+ if (!c-combine)
+ error(_(Bad notes.rewriteMode value: '%s'),
v);
}
- return 0;
- } else if (!c-refs_from_env !strcmp(k, notes.rewriteref)) {
+ }
+ if (!c-refs_from_env !git_config_get_value(notes.rewriteref, v))
{
/* note that a refs/ prefix is implied in the
* underlying for_each_glob_ref */
if (starts_with(v, refs/notes/))
@@ -92,10 +94,7 @@ static int notes_rewrite_config(const char *k, const char
*v, void *cb)
else
warning(_(Refusing to rewrite notes in %s
(outside of refs/notes/)), v);
- return 0;
}
-
- return 0;
}
@@ -124,7 +123,7 @@ struct notes_rewrite_cfg *init_copy_notes_for_rewrite(const
char *cmd)
c-refs_from_env = 1;
string_list_add_refs_from_colon_sep(c-refs, rewrite_refs_env);
}
- git_config(notes_rewrite_config, c);
+ notes_rewrite_config(c);
if (!c-enabled || !c-refs-nr) {
string_list_clear(c-refs, 0);
free(c-refs);
--
1.9.0.GIT
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/6] pager.c: replace `git_config()` with `git_config_get_value()`
Use `git_config_get_value()` instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
pager.c | 40 +---
1 file changed, 13 insertions(+), 27 deletions(-)
diff --git a/pager.c b/pager.c
index 8b5cbc5..b7eb7e7 100644
--- a/pager.c
+++ b/pager.c
@@ -6,12 +6,6 @@
#define DEFAULT_PAGER less
#endif
-struct pager_config {
- const char *cmd;
- int want;
- char *value;
-};
-
/*
* This is split up from the rest of git so that we can do
* something different on Windows.
@@ -155,30 +149,22 @@ int decimal_width(int number)
return width;
}
-static int pager_command_config(const char *var, const char *value, void *data)
+/* returns 0 for no pager, 1 for use pager, and -1 for not specified */
+int check_pager_config(const char *cmd)
{
- struct pager_config *c = data;
- if (starts_with(var, pager.) !strcmp(var + 6, c-cmd)) {
- int b = git_config_maybe_bool(var, value);
+ int want = -1;
+ struct strbuf key = STRBUF_INIT;
+ const char *value = NULL;
+ strbuf_addf(key, pager.%s, cmd);
+ if (!git_config_get_value(key.buf, value)) {
+ int b = git_config_maybe_bool(key.buf, value);
if (b = 0)
- c-want = b;
+ want = b;
else {
- c-want = 1;
- c-value = xstrdup(value);
+ want = 1;
+ pager_program = xstrdup(value);
}
}
- return 0;
-}
-
-/* returns 0 for no pager, 1 for use pager, and -1 for not specified */
-int check_pager_config(const char *cmd)
-{
- struct pager_config c;
- c.cmd = cmd;
- c.want = -1;
- c.value = NULL;
- git_config(pager_command_config, c);
- if (c.value)
- pager_program = c.value;
- return c.want;
+ strbuf_release(key);
+ return want;
}
--
1.9.0.GIT
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/6] imap-send.c: replace `git_config()` with `git_config_get_*()` family
Use `git_config_get_*()` family instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
The function now raises an error instead of dying in cases where a NULL value is
not allowed.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
imap-send.c | 62 +++--
1 file changed, 27 insertions(+), 35 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 524fbab..b7ec98a 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1326,43 +1326,35 @@ static int split_msg(struct strbuf *all_msgs, struct
strbuf *msg, int *ofs)
static char *imap_folder;
-static int git_imap_config(const char *key, const char *val, void *cb)
+static void git_imap_config(void)
{
- if (!skip_prefix(key, imap., key))
- return 0;
-
- /* check booleans first, and barf on others */
- if (!strcmp(sslverify, key))
- server.ssl_verify = git_config_bool(key, val);
- else if (!strcmp(preformattedhtml, key))
- server.use_html = git_config_bool(key, val);
- else if (!val)
- return config_error_nonbool(key);
-
- if (!strcmp(folder, key)) {
- imap_folder = xstrdup(val);
- } else if (!strcmp(host, key)) {
- if (starts_with(val, imap:))
- val += 5;
- else if (starts_with(val, imaps:)) {
- val += 6;
- server.use_ssl = 1;
+ const char *val = NULL;
+
+ git_config_get_bool(imap.sslverify, server.ssl_verify);
+ git_config_get_bool(imap.preformattedhtml, server.use_html);
+ git_config_get_string(imap.folder, (const char**)imap_folder);
+
+ if (!git_config_get_value(imap.host, val)) {
+ if(!val)
+ config_error_nonbool(imap.host);
+ else {
+ if (starts_with(val, imap:))
+ val += 5;
+ else if (starts_with(val, imaps:)) {
+ val += 6;
+ server.use_ssl = 1;
+ }
+ if (starts_with(val, //))
+ val += 2;
+ server.host = xstrdup(val);
}
- if (starts_with(val, //))
- val += 2;
- server.host = xstrdup(val);
- } else if (!strcmp(user, key))
- server.user = xstrdup(val);
- else if (!strcmp(pass, key))
- server.pass = xstrdup(val);
- else if (!strcmp(port, key))
- server.port = git_config_int(key, val);
- else if (!strcmp(tunnel, key))
- server.tunnel = xstrdup(val);
- else if (!strcmp(authmethod, key))
- server.auth_method = xstrdup(val);
+ }
- return 0;
+ git_config_get_string(imap.user, (const char**)server.user);
+ git_config_get_string(imap.pass, (const char**)server.pass);
+ git_config_get_string(imap.port, (const char**)server.port);
+ git_config_get_string(imap.tunnel, (const char**)server.tunnel);
+ git_config_get_string(imap.authmethod, (const
char**)server.auth_method);
}
int main(int argc, char **argv)
@@ -1383,7 +1375,7 @@ int main(int argc, char **argv)
usage(imap_send_usage);
setup_git_directory_gently(nongit_ok);
- git_config(git_imap_config, NULL);
+ git_imap_config();
if (!server.port)
server.port = server.use_ssl ? 993 : 143;
--
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/6] git_config callers rewritten with the new config cache API
[PATCH v3]: Most of Eric's suggestions has been implemented. See [2] for discussion. Also, new helpers introduced in v7 of the config-set API series have been used. See [1] for the documentation of the new functions. This series builds on the top of 5def4132 in pu or topic[1] in the mailing list with name git config cache special querying API utilizing the cache. All patches pass every test, but there is a catch, there is slight behaviour change in most of them where originally the callback returns config_error_nonbool() when it sees a NULL value for a key causing a die specified in git_parse_source in config.c. The die also prints the file name and the line number as, die(bad config file line %d in %s, cf-linenr, cf-name); We lose the fine grained error checking when switching to this method. Still, I will try to correct this anomaly in my next series. [1]: http://thread.gmane.org/gmane.comp.version-control.git/253862 [2]: http://thread.gmane.org/gmane.comp.version-control.git/252334 Tanay Abhra (6): alias.c | 27 +++ branch.c | 24 imap-send.c | 41 +++-- notes-utils.c | 33 - notes.c | 21 +++-- pager.c | 40 +--- 6 files changed, 62 insertions(+), 124 deletions(-) -- 1.9.0.GIT -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/6] alias.c: replace `git_config()` with `git_config_get_string()`
Use `git_config_get_string()` instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
The function now raises an error instead of dying when a NULL value is found.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
alias.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/alias.c b/alias.c
index 758c867..a453bd8 100644
--- a/alias.c
+++ b/alias.c
@@ -1,26 +1,13 @@
#include cache.h
-static const char *alias_key;
-static char *alias_val;
-
-static int alias_lookup_cb(const char *k, const char *v, void *cb)
-{
- const char *name;
- if (skip_prefix(k, alias., name) !strcmp(name, alias_key)) {
- if (!v)
- return config_error_nonbool(k);
- alias_val = xstrdup(v);
- return 0;
- }
- return 0;
-}
-
-char *alias_lookup(const char *alias)
+char *alias_lookup(const char* alias)
{
- alias_key = alias;
- alias_val = NULL;
- git_config(alias_lookup_cb, NULL);
- return alias_val;
+ const char *v = NULL;
+ struct strbuf key = STRBUF_INIT;
+ strbuf_addf(key, alias.%s, alias);
+ git_config_get_string(key.buf, v);
+ strbuf_release(key);
+ return (char*)v;
}
#define SPLIT_CMDLINE_BAD_ENDING 1
--
1.9.0.GIT
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/6] notes.c: replace `git_config()` with `git_config_get_value()`
Use `git_config_get_value()` instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow, also previously
'string_list_add_refs_by_glob()' was called even when the retrieved value
was NULL, correct it while we are at it.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
notes.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/notes.c b/notes.c
index 5fe691d..20c20f5 100644
--- a/notes.c
+++ b/notes.c
@@ -961,19 +961,6 @@ void string_list_add_refs_from_colon_sep(struct
string_list *list,
free(globs_copy);
}
-static int notes_display_config(const char *k, const char *v, void *cb)
-{
- int *load_refs = cb;
-
- if (*load_refs !strcmp(k, notes.displayref)) {
- if (!v)
- config_error_nonbool(k);
- string_list_add_refs_by_glob(display_notes_refs, v);
- }
-
- return 0;
-}
-
const char *default_notes_ref(void)
{
const char *notes_ref = NULL;
@@ -1041,6 +1028,7 @@ struct notes_tree **load_notes_trees(struct string_list
*refs)
void init_display_notes(struct display_notes_opt *opt)
{
char *display_ref_env;
+ const char *value = NULL;
int load_config_refs = 0;
display_notes_refs.strdup_strings = 1;
@@ -1058,7 +1046,12 @@ void init_display_notes(struct display_notes_opt *opt)
load_config_refs = 1;
}
- git_config(notes_display_config, load_config_refs);
+ if (load_config_refs !git_config_get_value(notes.displayref,
value)) {
+ if (!value)
+ config_error_nonbool(notes.displayref);
+ else
+ string_list_add_refs_by_glob(display_notes_refs,
value);
+ }
if (opt) {
struct string_list_item *item;
--
1.9.0.GIT
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] rewrite `git_default_config()` using config-set API functions
Use `git_config_get_*()` family instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
Consider this as a proof of concept as the others callers have to be rewritten
as well.
I think that it is not so buggy as it passes all the tests.
After the first six patches in the series which you have already seen there are
five or four left which can rewritten without touching git_default_config().
Thus, this rewrite will serve as the base for rewriting other git_config()
callers which pass control to git_default_config() at the end of the function.
Also there are more than thirty direct callers to git_default_config()
(i.e git_config(git_default_config, NULL)), so this rewrite solves them
in one sweep.
Slight behaviour change, config_error_nonbool() has been replaced with
die(Missing value for '%s', var);.
The original code also alerted the file name and the line number which we lose
here.
Cheers,
Tanay Abhra.
advice.c | 18 ++--
advice.h | 2 +-
cache.h | 2 +-
config.c | 287 ---
ident.c | 15 ++--
5 files changed, 104 insertions(+), 220 deletions(-)
diff --git a/advice.c b/advice.c
index 9b42033..92d89a9 100644
--- a/advice.c
+++ b/advice.c
@@ -59,22 +59,16 @@ void advise(const char *advice, ...)
strbuf_release(buf);
}
-int git_default_advice_config(const char *var, const char *value)
+void git_default_advice_config(void)
{
- const char *k;
+ struct strbuf var = STRBUF_INIT;
int i;
-
- if (!skip_prefix(var, advice., k))
- return 0;
-
for (i = 0; i ARRAY_SIZE(advice_config); i++) {
- if (strcmp(k, advice_config[i].name))
- continue;
- *advice_config[i].preference = git_config_bool(var, value);
- return 0;
+ strbuf_addf(var, advice.%s, advice_config[i].name);
+ git_config_get_bool(var.buf, advice_config[i].preference);
+ strbuf_reset(var);
}
-
- return 0;
+ strbuf_release(var);
}
int error_resolve_conflict(const char *me)
diff --git a/advice.h b/advice.h
index 5ecc6c1..5bfe46c 100644
--- a/advice.h
+++ b/advice.h
@@ -19,7 +19,7 @@ extern int advice_set_upstream_failure;
extern int advice_object_name_warning;
extern int advice_rm_hints;
-int git_default_advice_config(const char *var, const char *value);
+void git_default_advice_config(void);
__attribute__((format (printf, 1, 2)))
void advise(const char *advice, ...);
int error_resolve_conflict(const char *me);
diff --git a/cache.h b/cache.h
index e53651c..e667d92 100644
--- a/cache.h
+++ b/cache.h
@@ -1061,7 +1061,7 @@ extern const char *fmt_name(const char *name, const char
*email);
extern const char *ident_default_email(void);
extern const char *git_editor(void);
extern const char *git_pager(int stdout_is_tty);
-extern int git_ident_config(const char *, const char *, void *);
+extern void git_ident_config(void);
struct ident_split {
const char *name_begin;
diff --git a/config.c b/config.c
index fe9f399..72196a9 100644
--- a/config.c
+++ b/config.c
@@ -666,88 +666,47 @@ int git_config_pathname(const char **dest, const char
*var, const char *value)
return 0;
}
-static int git_default_core_config(const char *var, const char *value)
+static void git_default_core_config(void)
{
+ const char *value = NULL;
/* This needs a better name */
- if (!strcmp(var, core.filemode)) {
- trust_executable_bit = git_config_bool(var, value);
- return 0;
- }
- if (!strcmp(var, core.trustctime)) {
- trust_ctime = git_config_bool(var, value);
- return 0;
- }
- if (!strcmp(var, core.checkstat)) {
+ git_config_get_bool(core.filemode, trust_executable_bit);
+ git_config_get_bool(core.trustctime, trust_ctime);
+
+ if (!git_config_get_value(core.checkstat, value)) {
if (!strcasecmp(value, default))
check_stat = 1;
else if (!strcasecmp(value, minimal))
check_stat = 0;
}
- if (!strcmp(var, core.quotepath)) {
- quote_path_fully = git_config_bool(var, value);
- return 0;
- }
-
- if (!strcmp(var, core.symlinks)) {
- has_symlinks = git_config_bool(var, value);
- return 0;
- }
-
- if (!strcmp(var, core.ignorecase)) {
- ignore_case = git_config_bool(var, value);
- return 0;
- }
-
- if (!strcmp(var, core.attributesfile))
- return git_config_pathname(git_attributes_file, var, value);
-
- if (!strcmp(var, core.bare)) {
- is_bare_repository_cfg = git_config_bool(var, value);
- return 0;
- }
-
- if (!strcmp(var, core.ignorestat))
OSX packages on git-scm.com broken on previous OSX versions?
Hi, Apologies in advance if this is the wrong place, but it looks like the OSX packages available from http://git-scm.com/download/mac are not working for at least some people including myself. What I'm seeing is that any call to invoke git gives an illegal instruction, crash report is below. The other people are listed at: http://sourceforge.net/p/git-osx-installer/tickets/97/ Apparently this may be a problem caused by the lack of the compile flag -mmacosx-version-min=10.5 according to: http://stackoverflow.com/questions/14268887/what-is-the-illegal-instruction-4-error-and-why-does-mmacosx-version-min-10 Any chance this can be investigated and fixed please? cheers Dan Ackroyd btw I'm on OSX 10.6.8 but the other reports are on more up to date versions. Process: bash [90170] Path:/bin/bash Identifier: bash Version: ??? (???) Code Type: X86-64 (Native) Parent Process: bash [89840] Date/Time: 2014-07-21 12:34:59.093 +0100 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGILL) Exception Codes: KERN_INVALID_ADDRESS at 0xfff8 Crashed Thread: Unknown Backtrace not available Unknown thread crashed with X86 Thread State (64-bit): rax: 0x0055 rbx: 0x rcx: 0x rdx: 0x rdi: 0x rsi: 0x rbp: 0x rsp: 0x r8: 0x r9: 0x r10: 0x r11: 0x r12: 0x r13: 0x r14: 0x r15: 0x rip: 0x7fff5fc01028 rfl: 0x00010203 cr2: 0xfff8 Binary images description not available -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] git_config callers rewritten with the new config cache API
Tanay Abhra tanay...@gmail.com writes:
[PATCH v3]: Most of Eric's suggestions has been implemented. See [2] for
discussion.
Also, new helpers introduced in v7 of the config-set API series have
been used.
See [1] for the documentation of the new functions.
This series builds on the top of 5def4132 in pu or topic[1] in the mailing
list
with name git config cache special querying API utilizing the cache.
It's now called ta/config-set (see last What's cooking in git.git).
All patches pass every test, but there is a catch, there is slight behaviour
change in most of them where originally the callback returns
config_error_nonbool() when it sees a NULL value for a key causing a die
specified in git_parse_source in config.c.
The die also prints the file name and the line number as,
die(bad config file line %d in %s, cf-linenr, cf-name);
We lose the fine grained error checking when switching to this method.
I think a first step would be something like this:
--- a/config.c
+++ b/config.c
@@ -656,6 +656,15 @@ int git_config_string(const char **dest, const char *var,
const char *value)
return 0;
}
+// TODO: either make it static or export it properly
+int git_config_string_or_die(const char **dest, const char *var, const char
*value)
+{
+ if (git_config_string(dest, var, value) 0)
+ die(bad config file (TODO: file/line info));
+ else
+ return 0;
+}
+
int git_config_pathname(const char **dest, const char *var, const char *value)
{
if (!value)
@@ -1336,7 +1345,7 @@ int git_configset_get_string(struct config_set *cs, const
char *key, const char
{
const char *value;
if (!git_configset_get_value(cs, key, value))
- return git_config_string(dest, key, value);
+ return git_config_string_or_die(dest, key, value);
else
return 1;
}
In the original API, git_config_string was called at parsing time, hence
the file/line information was available through cf. Here, we're
querying the cache which doesn't have this information yet.
I initially thought that managing properly file/line information would
be just an addition, but this example shows that it is actually needed
to be feature-complete wrt the old API. And I think we should be
feature-complete (i.e. make the code cleaner without harming the user).
So, I think it now makes sense to resurect your file line info patch:
http://article.gmane.org/gmane.comp.version-control.git/253123
Now that the series is properly reviewed, avoid modifying existing
patches as much as possible, and add these file/line info on top of the
existing.
I think you need to:
1) Modify the hashmap data structure and the code that fills it in to
store the file/line info (already done in your previous WIP patch).
2) Add a by-address parameter to git_configset_get_value that allows the
user to get the file and line information. In your previous patch,
that would mean returning a pointer to the corresponding struct
key_source.
3) Pass this information to git_config_string_or_die, and die with the
right message (with a helper like die_config(struct key_source *ks)
that takes care of the formatting)
4) apply the same to git_config_get_other than string.
I'd actually add a step 0) before that: add a test that checks your
behavior change. The test should pass without your patches, and fail
with your current patch. Then, it should pass again once you completed
the work.
On a side note, re-reading your previous patch, I found this which
sounds suspicious:
+ struct config_hash_entry *e;
+ struct string_list_item *si;
+ struct key_source *ks = xmalloc(sizeof(*e));
Didn't you mean xmalloc(sizeof(*ks))?
^^
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] alias.c: replace `git_config()` with `git_config_get_string()`
Tanay Abhra tanay...@gmail.com writes:
--- a/alias.c
+++ b/alias.c
@@ -1,26 +1,13 @@
#include cache.h
-static const char *alias_key;
-static char *alias_val;
-
-static int alias_lookup_cb(const char *k, const char *v, void *cb)
-{
- const char *name;
- if (skip_prefix(k, alias., name) !strcmp(name, alias_key)) {
- if (!v)
- return config_error_nonbool(k);
- alias_val = xstrdup(v);
- return 0;
- }
- return 0;
-}
-
-char *alias_lookup(const char *alias)
+char *alias_lookup(const char* alias)
Style: keep the * stuck to alias.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] checkout: indicate when a detached head is checked out for a branch
Junio C Hamano venit, vidit, dixit 19.07.2014 00:18: Dennis Kaarsemaker den...@kaarsemaker.net writes: My use case for this is checking out the same branch (or commit, so already on a detached HEAD) in multiple different places to run independent actions (e.g. make test with different compiler options, or creating several different packages) and I would really appreciate it if that would keep working. I do not have any problem if multiple working trees have the same commit checked out on their own detached HEADs at all. The should error out was solely for the case where the user asked not to detach but to obtain a state where a named branch is checked out. In such a case, the command should not turn it into a detached HEAD, with or without a warning. Exactly, all of that, plus: * git checkout --detach --to foo bar could/should be a way to spell out git checkout --to foo bar^0. * In the case of erroring out, git checkout could suggest one of the above two commands. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] git_config callers rewritten with the new config cache API
On 7/21/2014 6:21 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com writes:
[PATCH v3]: Most of Eric's suggestions has been implemented. See [2] for
discussion.
Also, new helpers introduced in v7 of the config-set API series have
been used.
See [1] for the documentation of the new functions.
This series builds on the top of 5def4132 in pu or topic[1] in the mailing
list
with name git config cache special querying API utilizing the cache.
It's now called ta/config-set (see last What's cooking in git.git).
Noted. More below.
All patches pass every test, but there is a catch, there is slight behaviour
change in most of them where originally the callback returns
config_error_nonbool() when it sees a NULL value for a key causing a die
specified in git_parse_source in config.c.
The die also prints the file name and the line number as,
die(bad config file line %d in %s, cf-linenr, cf-name);
We lose the fine grained error checking when switching to this method.
I think a first step would be something like this:
--- a/config.c
+++ b/config.c
@@ -656,6 +656,15 @@ int git_config_string(const char **dest, const char
*var, const char *value)
return 0;
}
+// TODO: either make it static or export it properly
+int git_config_string_or_die(const char **dest, const char *var, const char
*value)
+{
+ if (git_config_string(dest, var, value) 0)
+ die(bad config file (TODO: file/line info));
+ else
+ return 0;
+}
+
int git_config_pathname(const char **dest, const char *var, const char
*value)
{
if (!value)
@@ -1336,7 +1345,7 @@ int git_configset_get_string(struct config_set *cs,
const char *key, const char
{
const char *value;
if (!git_configset_get_value(cs, key, value))
- return git_config_string(dest, key, value);
+ return git_config_string_or_die(dest, key, value);
else
return 1;
}
In the original API, git_config_string was called at parsing time, hence
the file/line information was available through cf. Here, we're
querying the cache which doesn't have this information yet.
I initially thought that managing properly file/line information would
be just an addition, but this example shows that it is actually needed
to be feature-complete wrt the old API. And I think we should be
feature-complete (i.e. make the code cleaner without harming the user).
So, I think it now makes sense to resurect your file line info patch:
http://article.gmane.org/gmane.comp.version-control.git/253123
Now that the series is properly reviewed, avoid modifying existing
patches as much as possible, and add these file/line info on top of the
existing.
I think you need to:
1) Modify the hashmap data structure and the code that fills it in to
store the file/line info (already done in your previous WIP patch).
2) Add a by-address parameter to git_configset_get_value that allows the
user to get the file and line information. In your previous patch,
that would mean returning a pointer to the corresponding struct
key_source.
Will this extra complexity be good for git_configset_get_value?
Instead can we provide a function like die_config(char *key)
which prints
die(bad config file line %d in %s, linenr, filename);?
A variation would be die_config_multi(char *key, char *value)
for multi valued keys.
3) Pass this information to git_config_string_or_die, and die with the
right message (with a helper like die_config(struct key_source *ks)
that takes care of the formatting)
No need for passing if we use the above method. We will just call die_config()
inside it for NULL values
4) apply the same to git_config_get_other than string.
I'd actually add a step 0) before that: add a test that checks your
behavior change. The test should pass without your patches, and fail
with your current patch. Then, it should pass again once you completed
the work.
Noted, I will add it.
On a side note, re-reading your previous patch, I found this which
sounds suspicious:
+ struct config_hash_entry *e;
+ struct string_list_item *si;
+ struct key_source *ks = xmalloc(sizeof(*e));
Didn't you mean xmalloc(sizeof(*ks))?
Yikes, Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] Make locked paths absolute when current directory is changed
On 20/07/14 13:13, Nguyễn Thái Ngọc Duy wrote:
Locked paths are saved in a linked list so that if something wrong
happens, *.lock are removed. This works fine if we keep cwd the same,
which is true 99% of time except:
- update-index and read-tree hold the lock on $GIT_DIR/index really
early, then later on may call setup_work_tree() to move cwd.
- Suppose a lock is being held (e.g. by git add) then somewhere
down the line, somebody calls real_path (e.g. link_alt_odb_entry),
which temporarily moves cwd away and back.
During that time when cwd is moved (either permanently or temporarily)
and we decide to die(), attempts to remove relative *.lock will fail,
and the next operation will complain that some files are still locked.
Avoid this case by turning relative paths to absolute when chdir() is
called (or soon to be called, in setup_git_directory_gently case).
Reported-by: Yue Lin Ho yuelinho...@gmail.com
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
[snip]
diff --git a/lockfile.c b/lockfile.c
index 968b28f..cf1e795 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -288,3 +288,15 @@ void rollback_lock_file(struct lock_file *lk)
}
clear_filename(lk);
}
+
+void make_locked_paths_absolute(void)
+{
+ struct lock_file *lk;
+ for (lk = lock_file_list; lk != NULL; lk = lk-next) {
+ if (lk-filename !is_absolute_path(lk-filename)) {
+ char *to_free = lk-filename;
+ lk-filename = xstrdup(absolute_path(lk-filename));
+ free(to_free);
+ }
+ }
+}
I just have to ask, why are we putting relative pathnames in this
list to begin with? Why not use an absolute path when taking the
lock in all cases? (calling absolute_path() and using the result
to take the lock, storing it in the lock_file list, should not be
in the critical path, right? Not that I have measured it, of course! :)
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] alias.c: replace `git_config()` with `git_config_get_string()`
On 21/07/14 12:12, Tanay Abhra wrote:
Use `git_config_get_string()` instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
The function now raises an error instead of dying when a NULL value is found.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
alias.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/alias.c b/alias.c
index 758c867..a453bd8 100644
--- a/alias.c
+++ b/alias.c
@@ -1,26 +1,13 @@
#include cache.h
-static const char *alias_key;
-static char *alias_val;
-
-static int alias_lookup_cb(const char *k, const char *v, void *cb)
-{
- const char *name;
- if (skip_prefix(k, alias., name) !strcmp(name, alias_key)) {
- if (!v)
- return config_error_nonbool(k);
- alias_val = xstrdup(v);
- return 0;
- }
- return 0;
-}
-
-char *alias_lookup(const char *alias)
+char *alias_lookup(const char* alias)
No, this is not C++. :-D
{
- alias_key = alias;
- alias_val = NULL;
- git_config(alias_lookup_cb, NULL);
- return alias_val;
+ const char *v = NULL;
+ struct strbuf key = STRBUF_INIT;
+ strbuf_addf(key, alias.%s, alias);
+ git_config_get_string(key.buf, v);
+ strbuf_release(key);
+ return (char*)v;
}
#define SPLIT_CMDLINE_BAD_ENDING 1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] rewrite `git_default_config()` using config-set API functions
Tanay Abhra tanay...@gmail.com writes:
Consider this as a proof of concept as the others callers have to be rewritten
as well.
I think that it is not so buggy as it passes all the tests.
Before and after your patch, git_default_config() is called once per
config key. Before the patch, it made sense, but after the patch, it
doesn't anymore, as it loads the whole config file in one call.
I think it's OK to have this as an intermediate patch, but it should be
clear to reviewers.
At the end of your series, git_default_config should become an
argumentless function.
Actually, I'm wondering whether it makes sense to keep
git_default_config as-is, and introduce a new function like
git_load_default_config(void), initially empty. Then, move and change
code from git_default_config(...) to git_load_default_config(), and
finally remove git_default_config(...) once it's empty.
You have several decl-after-statements in your patch. You should have
something like this in config.mak to catch them:
CFLAGS += -Wdeclaration-after-statement -Wall -Werror
There are several (long unsigned int*) casts that seem useless to me.
Useless casts distract the reader, and prevent usefull warnings from the
compiler.
Actually, I'm wondering whether these casts are safe (they cast from
size_t * to ulong *). On Windows 64 bits for example, sizeof(size_t) ==
8 and sizeof(unsigned long) == 4 if google informed me correctly. On a
big-endian machine, this would be totally broken.
It is probably safer to add a new git_config_get_size_t analog to
git_config_get_ulong.
+ if + git_config_get_string(core.notesref, (const
char**)notes_ref_name);
This cast is needed only because notes_ref_name is declared as
non-const, but a better fix would be to make the variable const, and
remove the cast.
The following patch solves these issues (modulo the question above on
cast safety).
diff --git a/cache.h b/cache.h
index e667d92..1271904 100644
--- a/cache.h
+++ b/cache.h
@@ -674,7 +674,7 @@ enum object_creation_mode {
extern enum object_creation_mode object_creation_mode;
-extern char *notes_ref_name;
+extern const char *notes_ref_name;
extern int grafts_replace_parents;
diff --git a/config.c b/config.c
index 72196a9..c2664c3 100644
--- a/config.c
+++ b/config.c
@@ -669,6 +669,9 @@ int git_config_pathname(const char **dest, const char *var,
const char *value)
static void git_default_core_config(void)
{
const char *value = NULL;
+ int abbrev;
+ int level;
+ const char *comment;
/* This needs a better name */
git_config_get_bool(core.filemode, trust_executable_bit);
git_config_get_bool(core.trustctime, trust_ctime);
@@ -690,13 +693,11 @@ static void git_default_core_config(void)
git_config_get_bool(core.logallrefupdates, log_all_ref_updates);
git_config_get_bool(core.warnambiguousrefs, warn_ambiguous_refs);
- int abbrev;
if (!git_config_get_int(core.abbrev, abbrev)) {
if (abbrev = minimum_abbrev abbrev = 40)
default_abbrev = abbrev;
}
- int level;
if (!git_config_get_int(core.loosecompression, level)) {
if (level == -1)
level = Z_DEFAULT_COMPRESSION;
@@ -717,7 +718,7 @@ static void git_default_core_config(void)
zlib_compression_level = level;
}
- if (!git_config_get_ulong(core.packedgitwindowsize, (long unsigned
int*)packed_git_window_size)) {
+ if (!git_config_get_ulong(core.packedgitwindowsize,
packed_git_window_size)) {
int pgsz_x2 = getpagesize() * 2;
/* This value must be multiple of (pagesize * 2) */
@@ -728,8 +729,8 @@ static void git_default_core_config(void)
}
git_config_get_ulong(core.bigfilethreshold, big_file_threshold);
- git_config_get_ulong(core.packedgitlimit, (long unsigned
int*)packed_git_limit);
- git_config_get_ulong(core.deltabasecachelimit, (long unsigned
int*)delta_base_cache_limit);
+ git_config_get_ulong(core.packedgitlimit, packed_git_limit);
+ git_config_get_ulong(core.deltabasecachelimit,
delta_base_cache_limit);
if (!git_config_get_value(core.autocrlf, value)) {
if (value !strcasecmp(value, input)) {
@@ -760,11 +761,10 @@ static void git_default_core_config(void)
die(core.autocrlf=input conflicts with core.eol=crlf);
}
- git_config_get_string(core.notesref, (const char**)notes_ref_name);
+ git_config_get_string(core.notesref, notes_ref_name);
git_config_get_string(core.pager, pager_program);
git_config_get_string(core.editor, editor_program);
- const char *comment;
if (!git_config_get_string(core.commentchar, comment)) {
if (!strcasecmp(comment, auto))
auto_comment_line_char = 1;
diff --git a/environment.c b/environment.c
index 565f652..21d4dbb
Re: [PATCH v3 0/6] git_config callers rewritten with the new config cache API
Tanay Abhra tanay...@gmail.com writes: On 7/21/2014 6:21 PM, Matthieu Moy wrote: 2) Add a by-address parameter to git_configset_get_value that allows the user to get the file and line information. In your previous patch, that would mean returning a pointer to the corresponding struct key_source. Will this extra complexity be good for git_configset_get_value? Instead can we provide a function like die_config(char *key) which prints die(bad config file line %d in %s, linenr, filename);? Where would you call this function, and where would you take linenr and filename? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] Make locked paths absolute when current directory is changed
On Mon, Jul 21, 2014 at 8:27 PM, Ramsay Jones
ram...@ramsay1.demon.co.uk wrote:
+void make_locked_paths_absolute(void)
+{
+ struct lock_file *lk;
+ for (lk = lock_file_list; lk != NULL; lk = lk-next) {
+ if (lk-filename !is_absolute_path(lk-filename)) {
+ char *to_free = lk-filename;
+ lk-filename = xstrdup(absolute_path(lk-filename));
+ free(to_free);
+ }
+ }
+}
I just have to ask, why are we putting relative pathnames in this
list to begin with? Why not use an absolute path when taking the
lock in all cases? (calling absolute_path() and using the result
to take the lock, storing it in the lock_file list, should not be
in the critical path, right? Not that I have measured it, of course! :)
Conservative :) I'm still scared from 044bbbc (Make git_dir a path
relative to work_tree in setup_work_tree() - 2008-06-19). But yeah
looking through grep hold_ I think none of the locks is in critical
path. absolute_path() can die() if cwd is longer than PATH_MAX (and
doing this reduces the chances of that happening). But René is adding
strbuf_getcwd() that can remove that PATH_MAX. So I guess we should be
fine with putting absolute_path() in hold_lock_file_...*
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] rewrite `git_default_config()` using config-set API functions
On 21/07/14 12:44, Tanay Abhra wrote:
Use `git_config_get_*()` family instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
Consider this as a proof of concept as the others callers have to be rewritten
as well.
I think that it is not so buggy as it passes all the tests.
After the first six patches in the series which you have already seen there
are
five or four left which can rewritten without touching git_default_config().
Thus, this rewrite will serve as the base for rewriting other git_config()
callers which pass control to git_default_config() at the end of the function.
Also there are more than thirty direct callers to git_default_config()
(i.e git_config(git_default_config, NULL)), so this rewrite solves them
in one sweep.
Slight behaviour change, config_error_nonbool() has been replaced with
die(Missing value for '%s', var);.
The original code also alerted the file name and the line number which we
lose here.
Cheers,
Tanay Abhra.
advice.c | 18 ++--
advice.h | 2 +-
cache.h | 2 +-
config.c | 287
---
ident.c | 15 ++--
5 files changed, 104 insertions(+), 220 deletions(-)
[snip]
diff --git a/config.c b/config.c
index fe9f399..72196a9 100644
--- a/config.c
+++ b/config.c
@@ -666,88 +666,47 @@ int git_config_pathname(const char **dest, const char
*var, const char *value)
return 0;
}
-static int git_default_core_config(const char *var, const char *value)
+static void git_default_core_config(void)
{
+ const char *value = NULL;
/* This needs a better name */
- if (!strcmp(var, core.filemode)) {
- trust_executable_bit = git_config_bool(var, value);
- return 0;
- }
- if (!strcmp(var, core.trustctime)) {
- trust_ctime = git_config_bool(var, value);
- return 0;
- }
- if (!strcmp(var, core.checkstat)) {
+ git_config_get_bool(core.filemode, trust_executable_bit);
+ git_config_get_bool(core.trustctime, trust_ctime);
+
+ if (!git_config_get_value(core.checkstat, value)) {
if (!strcasecmp(value, default))
check_stat = 1;
else if (!strcasecmp(value, minimal))
check_stat = 0;
}
- if (!strcmp(var, core.quotepath)) {
- quote_path_fully = git_config_bool(var, value);
- return 0;
- }
-
- if (!strcmp(var, core.symlinks)) {
- has_symlinks = git_config_bool(var, value);
- return 0;
- }
-
- if (!strcmp(var, core.ignorecase)) {
- ignore_case = git_config_bool(var, value);
- return 0;
- }
-
- if (!strcmp(var, core.attributesfile))
- return git_config_pathname(git_attributes_file, var, value);
-
- if (!strcmp(var, core.bare)) {
- is_bare_repository_cfg = git_config_bool(var, value);
- return 0;
- }
-
- if (!strcmp(var, core.ignorestat)) {
- assume_unchanged = git_config_bool(var, value);
- return 0;
- }
-
- if (!strcmp(var, core.prefersymlinkrefs)) {
- prefer_symlink_refs = git_config_bool(var, value);
- return 0;
- }
-
- if (!strcmp(var, core.logallrefupdates)) {
- log_all_ref_updates = git_config_bool(var, value);
- return 0;
- }
+ git_config_get_bool(core.quotepath, quote_path_fully);
+ git_config_get_bool(core.symlinks, has_symlinks);
+ git_config_get_bool(core.ignorecase, ignore_case);
+ git_config_get_pathname(core.attributesfile, git_attributes_file);
+ git_config_get_bool(core.bare, is_bare_repository_cfg);
+ git_config_get_bool(core.ignorestat, assume_unchanged);
+ git_config_get_bool(core.prefersymlinkrefs, prefer_symlink_refs);
+ git_config_get_bool(core.logallrefupdates, log_all_ref_updates);
+ git_config_get_bool(core.warnambiguousrefs, warn_ambiguous_refs);
- if (!strcmp(var, core.warnambiguousrefs)) {
- warn_ambiguous_refs = git_config_bool(var, value);
- return 0;
+ int abbrev;
declaration after statement.
+ if (!git_config_get_int(core.abbrev, abbrev)) {
+ if (abbrev = minimum_abbrev abbrev = 40)
+ default_abbrev = abbrev;
}
- if (!strcmp(var, core.abbrev)) {
- int abbrev = git_config_int(var, value);
- if (abbrev minimum_abbrev || abbrev 40)
- return -1;
- default_abbrev = abbrev;
- return 0;
- }
-
- if (!strcmp(var, core.loosecompression)) {
- int level = git_config_int(var, value);
+ int level;
ditto.
+ if (!git_config_get_int(core.loosecompression, level)) {
Re: [PATCH v3 0/6] git_config callers rewritten with the new config cache API
On 7/21/2014 7:15 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com writes:
On 7/21/2014 6:21 PM, Matthieu Moy wrote:
2) Add a by-address parameter to git_configset_get_value that allows the
user to get the file and line information. In your previous patch,
that would mean returning a pointer to the corresponding struct
key_source.
Will this extra complexity be good for git_configset_get_value?
Instead can we provide a function like die_config(char *key)
which prints
die(bad config file line %d in %s, linenr, filename);?
Where would you call this function, and where would you take linenr and
filename?
Usage can be like this,
if(!git_config_get_value(k, v)) {
if (!v) {
config_error_nonbool(k);
die_config(k);
/* die_config calls git_config_get_value_multi for 'k',
* gets the string list with the util pointer containing
* the linenr and the file name, dies printing the message.
*/
} else
/* do work */
}
Above example works just like the current code. Currently the callbacks
does not have the access to the linenr and file name anyway.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug in get_pwd_cwd() in Windows?
This function tests if $PWD is the same as getcwd() using st_dev and st_ino. But on Windows these fields are always zero (mingw.c:do_lstat). If cwd is moved away, I think falling back to $PWD is wrong. I don't understand the use of $PWD in the first place. 1b9a946 (Use nonrelative paths instead of absolute paths for cloned repositories - 2008-06-05) does not explain much. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] rewrite `git_default_config()` using config-set API functions
+if + git_config_get_string(core.notesref, (const char**)notes_ref_name); This cast is needed only because notes_ref_name is declared as non-const, but a better fix would be to make the variable const, and remove the cast. Same casts had to be used in imap-send.c patch, I will have to use an intermediate variable there to remove the cast thus destroying the one liners or will have to update the variable declarations. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] Make locked paths absolute when current directory is changed
On 21/07/14 14:47, Duy Nguyen wrote:
On Mon, Jul 21, 2014 at 8:27 PM, Ramsay Jones
ram...@ramsay1.demon.co.uk wrote:
+void make_locked_paths_absolute(void)
+{
+ struct lock_file *lk;
+ for (lk = lock_file_list; lk != NULL; lk = lk-next) {
+ if (lk-filename !is_absolute_path(lk-filename)) {
+ char *to_free = lk-filename;
+ lk-filename = xstrdup(absolute_path(lk-filename));
+ free(to_free);
+ }
+ }
+}
I just have to ask, why are we putting relative pathnames in this
list to begin with? Why not use an absolute path when taking the
lock in all cases? (calling absolute_path() and using the result
to take the lock, storing it in the lock_file list, should not be
in the critical path, right? Not that I have measured it, of course! :)
Conservative :) I'm still scared from 044bbbc (Make git_dir a path
relative to work_tree in setup_work_tree() - 2008-06-19). But yeah
looking through grep hold_ I think none of the locks is in critical
path. absolute_path() can die() if cwd is longer than PATH_MAX (and
doing this reduces the chances of that happening). But René is adding
strbuf_getcwd() that can remove that PATH_MAX. So I guess we should be
fine with putting absolute_path() in hold_lock_file_...*
Hmm, yes, thank you for reminding me about 044bbbc. So, yes it could
cause a (small) performance hit and a change in behaviour (die) in
deeply nested working directories. Hmm, OK.
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] git_config callers rewritten with the new config cache API
Tanay Abhra tanay...@gmail.com writes:
On 7/21/2014 7:15 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com writes:
On 7/21/2014 6:21 PM, Matthieu Moy wrote:
2) Add a by-address parameter to git_configset_get_value that allows the
user to get the file and line information. In your previous patch,
that would mean returning a pointer to the corresponding struct
key_source.
Will this extra complexity be good for git_configset_get_value?
Instead can we provide a function like die_config(char *key)
which prints
die(bad config file line %d in %s, linenr, filename);?
Where would you call this function, and where would you take linenr and
filename?
Usage can be like this,
if(!git_config_get_value(k, v)) {
if (!v) {
config_error_nonbool(k);
die_config(k);
/* die_config calls git_config_get_value_multi for 'k',
* gets the string list with the util pointer containing
* the linenr and the file name, dies printing the message.
*/
} else
/* do work */
}
OK, so you query the cache twice (which is OK, it's cheap and happens
just once before dying). That would work too.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] rewrite `git_default_config()` using config-set API functions
Tanay Abhra tanay...@gmail.com writes:
+ if + git_config_get_string(core.notesref, (const
char**)notes_ref_name);
This cast is needed only because notes_ref_name is declared as
non-const, but a better fix would be to make the variable const, and
remove the cast.
Same casts had to be used in imap-send.c patch, I will have to use an
intermediate variable there to remove the cast thus destroying the one
liners or will have to update the variable declarations.
Updating the declaration like this should just work:
--- a/imap-send.c
+++ b/imap-send.c
@@ -1324,7 +1324,7 @@ static int split_msg(struct strbuf *all_msgs, struct
strbuf *msg, int *ofs)
return 1;
}
-static char *imap_folder;
+static const char *imap_folder;
static void git_imap_config(void)
{
@@ -1332,7 +1332,7 @@ static void git_imap_config(void)
git_config_get_bool(imap.sslverify, server.ssl_verify);
git_config_get_bool(imap.preformattedhtml, server.use_html);
- git_config_get_string(imap.folder, (const char**)imap_folder);
+ git_config_get_string(imap.folder, imap_folder);
if (!git_config_get_value(imap.host, val)) {
if(!val)
In general, most strings one manipulates are const char *, it's
frequent to modify a pointer to a string, but rather rare to modify the
string itself.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Kedves Email felhasználói;
-- Kedves Email felhasználói; Túllépte a határt 23.432 tárolása az e-postafiók beállítva a WEB SERVICE / Administrator, és akkor problémái küldött és a bejövő üzenetek, amíg meg újból érvényesíti az e-mail címét. A szükséges eljárások nyújtottak be az alábbi a véleménye, ellenőrizze kattintva Az alábbi linkre és töltse ki az adatokat, hogy érvényesítse az e-mail címét. Kérjük, kattintson ide http://mailupdattwww2.jigsy.com/ Növelni az e-mail kvótát az e-mail. Figyelem! Ennek elmulasztása azt eredményezi, hogy korlátozott hozzáférést a postafiók. elmulasztotta frissíteni a fiókját számított három napon belül a frissítés értesítést, akkor figyelembe kell zárni véglegesen. Tisztelettel, Rendszergazda ® -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fixup! Win32: Unicode environment (outgoing)
Karsten Blees karsten.bl...@gmail.com writes:
compat/mingw.c needs to #include cache.h for ALLOC_GROW.
Signed-off-by: Karsten Blees bl...@dcon.de
---
Thanks!
compat/mingw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/compat/mingw.c b/compat/mingw.c
index bd45950..c725a3e 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -4,6 +4,7 @@
#include wchar.h
#include ../strbuf.h
#include ../run-command.h
+#include ../cache.h
static const int delay[] = { 0, 1, 10, 20, 40 };
--
2.0.2.897.g7f80809.dirty
--
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t0110/MinGW: skip tests that pass arbitrary bytes on the command line
Karsten Blees karsten.bl...@gmail.com writes: On Windows, the command line is a Unicode string, it is not possible to pass arbitrary bytes to a program. Disable tests that try to do so. Signed-off-by: Karsten Blees bl...@dcon.de --- Thanks; will replace. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] t4210: skip command-line encoding tests on mingw
Erik Faye-Lund kusmab...@gmail.com writes: On Thu, Jul 17, 2014 at 5:37 PM, Stepan Kasal ka...@ucw.cz wrote: From: Pat Thoyts pattho...@users.sourceforge.net On Windows the application command line is provided as unicode and in mingw-git we convert that to utf-8. So these tests that require a iso-8859-1 input are being subverted by the encoding transformations we perform and should be skipped. ... -test_expect_success 'log --grep searches in log output encoding (latin1)' ' +test_expect_success NOT_MINGW 'log --grep searches in log output encoding (latin1)' ' cat expect -\EOF latin1 utf8 @@ -43,7 +43,7 @@ test_expect_success 'log --grep searches in log output encoding (latin1)' ' test_cmp expect actual ' -test_expect_success 'log --grep does not find non-reencoded values (utf8)' ' +test_expect_success NOT_MINGW 'log --grep does not find non-reencoded values (utf8)' ' Perhaps these checks would be more readable a few years in the future, if we make a separate capability along the lines of NON_UNICODE_LOCALE? I do agree that having unicode and possibly also locale and dropping mingw from the prerequisite makes sense, especially in the longer term. Please make it so _after_ the dust settles. I however suspect that NON_UNICODE_LOCALE does not read quite well; isn't the trouble that mingw allows nothing but unicode strings on the command line (there is no trouble for non unicode strings that appear as payload)? Oh by the way, can somebody remind me why we spell these as NOT_MINGW, instead of !MINGW? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] Make locked paths absolute when current directory is changed
Duy Nguyen pclo...@gmail.com writes:
On Mon, Jul 21, 2014 at 8:27 PM, Ramsay Jones
ram...@ramsay1.demon.co.uk wrote:
+void make_locked_paths_absolute(void)
+{
+ struct lock_file *lk;
+ for (lk = lock_file_list; lk != NULL; lk = lk-next) {
+ if (lk-filename !is_absolute_path(lk-filename)) {
+ char *to_free = lk-filename;
+ lk-filename = xstrdup(absolute_path(lk-filename));
+ free(to_free);
+ }
+ }
+}
I just have to ask, why are we putting relative pathnames in this
list to begin with? Why not use an absolute path when taking the
lock in all cases? (calling absolute_path() and using the result
to take the lock, storing it in the lock_file list, should not be
in the critical path, right? Not that I have measured it, of course! :)
Conservative :) I'm still scared from 044bbbc (Make git_dir a path
relative to work_tree in setup_work_tree() - 2008-06-19). But yeah
looking through grep hold_ I think none of the locks is in critical
path. absolute_path() can die() if cwd is longer than PATH_MAX (and
doing this reduces the chances of that happening). But René is adding
strbuf_getcwd() that can remove that PATH_MAX. So I guess we should be
fine with putting absolute_path() in hold_lock_file_...*
OK, we should center these efforts around the strbuf_getcwd() topic,
basing the other topic on realpath() and this one on it then?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] use strbuf_getcwd() to get the current working directory without fixed-sized buffers
Am 21.07.2014 04:33, schrieb Jeff King:
On Sun, Jul 20, 2014 at 06:49:54PM +0200, René Scharfe wrote:
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 56f85e2..c4958b6 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -535,10 +535,10 @@ int cmd_init_db(int argc, const char **argv, const char
*prefix)
usage(init_db_usage[0]);
}
if (is_bare_repository_cfg == 1) {
- static char git_dir[PATH_MAX+1];
-
- setenv(GIT_DIR_ENVIRONMENT,
- getcwd(git_dir, sizeof(git_dir)), argc 0);
+ struct strbuf cwd = STRBUF_INIT;
+ strbuf_getcwd(cwd);
+ setenv(GIT_DIR_ENVIRONMENT, cwd.buf, argc 0);
+ strbuf_release(cwd);
Hmm. You are not making anything worse here, as we already do not check
the return value of getcwd. But what happens if it fails? Looks like we
currently get a segfault, and the new code will silently set the
variable to the empty string. Neither is particularly helpful.
Should we be using the xgetcwd helper that you add in the next patch?
Probably. And I was so glad to have found an example case for getcwd
without dying and without touching the get-there-and-back cases. :)
Guess I'll have to look closer at setup.c and perhaps unix-socket.c for
a replacement.
By the way: Simply setting $GIT_DIR to . probably won't work in the
two cases, I guess?
- setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir,
sizeof(git_dir)), 0);
+ strbuf_getcwd(cwd);
+ setenv(GIT_DIR_ENVIRONMENT, cwd.buf, 0);
+ strbuf_release(cwd);
Ditto here.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Why C pure? What IDE/tools?
curious: I am only an occasional programmer in C. I read Linus' post that C++ is a horrible language. alas, I wonder why people like Linus, who live in C, do not design C 11.1---a preprocessor or preprocessor replacement that adds some modest niceties to the language. For example, forward references and auto-header generation. For example, a shorter way to state #ifndef X #define X #endif . For example, propagation of '...' and optional arguments. Many others. It would be a collection of small improvements, some copied from C++ (or other languages), that make the actual C kernel code programming more pleasant. I don't mean a full new language, like C++ or D. over time, given the prominence of the kernel and Linus, this could even morph into a quasi-standard with toolchain and IDE support. Not a full new language, just modest C language programming pleasantry enhancements. what IDE and tools does Linus use? (I do know linux and git! ;-).) do these tools make enhancements less useful?!? /iaw -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] completion: add missing terminator in case statement
John Keeping j...@keeping.me.uk writes: Signed-off-by: John Keeping j...@keeping.me.uk --- As these ;; are separators not terminators, this is not strictly necessary. Squashing it into a change that adds more case arms to this case statement is of course not just good but necessary, though. contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 7a6e1d7..d0b2895 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1627,6 +1627,7 @@ _git_push () --repo) __gitcomp_nl $(__git_remotes) return + ;; esac case $cur in --repo=*) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 4/6] t4210: skip command-line encoding tests on mingw
Hi Junio, On Mon, 21 Jul 2014, Junio C Hamano wrote: Oh by the way, can somebody remind me why we spell these as NOT_MINGW, instead of !MINGW? I guess that is my mistake; when I introduced the use of NOT_MINGW I was simply unaware of the !MINGW syntax. Let's use the latter consistently? Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/6] branch.c: replace `git_config()` with `git_config_get_string()`
Tanay Abhra tanay...@gmail.com writes:
Use `git_config_get_string()` instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
branch.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/branch.c b/branch.c
index 46e8aa8..827307f 100644
--- a/branch.c
+++ b/branch.c
@@ -140,33 +140,17 @@ static int setup_tracking(const char *new_ref, const
char *orig_ref,
return 0;
}
-struct branch_desc_cb {
- const char *config_name;
- const char *value;
-};
-
-static int read_branch_desc_cb(const char *var, const char *value, void *cb)
-{
- struct branch_desc_cb *desc = cb;
- if (strcmp(desc-config_name, var))
- return 0;
- free((char *)desc-value);
- return git_config_string(desc-value, var, value);
-}
-
int read_branch_desc(struct strbuf *buf, const char *branch_name)
{
- struct branch_desc_cb cb;
+ const char *v = NULL;
struct strbuf name = STRBUF_INIT;
strbuf_addf(name, branch.%s.description, branch_name);
- cb.config_name = name.buf;
- cb.value = NULL;
- if (git_config(read_branch_desc_cb, cb) 0) {
+ if (git_config_get_string(name.buf, v)) {
strbuf_release(name);
return -1;
}
- if (cb.value)
- strbuf_addstr(buf, cb.value);
+ strbuf_addstr(buf, v);
+ free((char*)v);
In this cast, I smell an API mistake to insist an extra constness to
the output parameter of git_config_get_string() in [3/4] of the
previous series. Unlike the underlying git_config_get_value(),
which lets the caller peek into the internal cached copy, the caller
of git_config_get_string() is given its own copy, and I do not
offhand see a good reason to forbid the caller from modifying it.
strbuf_release(name);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] imap-send.c: replace `git_config()` with `git_config_get_*()` family
Tanay Abhra tanay...@gmail.com writes: + git_config_get_string(imap.folder, (const char**)imap_folder); The same why (const char **)--is that an API mistake? question applies here and other calls to git_config_get_string() in this patch. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/6] branch.c: replace `git_config()` with `git_config_get_string()`
Junio C Hamano gits...@pobox.com writes: Tanay Abhra tanay...@gmail.com writes: -if (cb.value) -strbuf_addstr(buf, cb.value); +strbuf_addstr(buf, v); +free((char*)v); In this cast, I smell an API mistake to insist an extra constness to the output parameter of git_config_get_string() in [3/4] of the previous series. Unlike the underlying git_config_get_value(), which lets the caller peek into the internal cached copy, the caller of git_config_get_string() is given its own copy, and I do not offhand see a good reason to forbid the caller from modifying it. Indeed. My suggestion to change the declaration of char * variables actually seem like a workaround for an API mistake after reading this. (well, actually, the declaration could be modified if we think it brings any new safety, but that should be another topic) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] rewrite `git_default_config()` using config-set API functions
Matthieu Moy matthieu@grenoble-inp.fr writes: In general, most strings one manipulates are const char *, it's frequent to modify a pointer to a string, but rather rare to modify the string itself. We seem to have a disagreement. Unlike git_config_get_value() that lets callers peek the only cached copy, git_config_get_string() gives its caller a new copy that the caller needs to free. Such a new string can and should be given as mutable, I would say. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/6] branch.c: replace `git_config()` with `git_config_get_string()`
On 7/21/2014 11:29 PM, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com writes:
Use `git_config_get_string()` instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
branch.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/branch.c b/branch.c
index 46e8aa8..827307f 100644
--- a/branch.c
+++ b/branch.c
@@ -140,33 +140,17 @@ static int setup_tracking(const char *new_ref, const
char *orig_ref,
return 0;
}
-struct branch_desc_cb {
-const char *config_name;
-const char *value;
-};
-
-static int read_branch_desc_cb(const char *var, const char *value, void *cb)
-{
-struct branch_desc_cb *desc = cb;
-if (strcmp(desc-config_name, var))
-return 0;
-free((char *)desc-value);
-return git_config_string(desc-value, var, value);
-}
-
int read_branch_desc(struct strbuf *buf, const char *branch_name)
{
-struct branch_desc_cb cb;
+const char *v = NULL;
struct strbuf name = STRBUF_INIT;
strbuf_addf(name, branch.%s.description, branch_name);
-cb.config_name = name.buf;
-cb.value = NULL;
-if (git_config(read_branch_desc_cb, cb) 0) {
+if (git_config_get_string(name.buf, v)) {
strbuf_release(name);
return -1;
}
-if (cb.value)
-strbuf_addstr(buf, cb.value);
+strbuf_addstr(buf, v);
+free((char*)v);
In this cast, I smell an API mistake to insist an extra constness to
the output parameter of git_config_get_string() in [3/4] of the
previous series. Unlike the underlying git_config_get_value(),
which lets the caller peek into the internal cached copy, the caller
of git_config_get_string() is given its own copy, and I do not
offhand see a good reason to forbid the caller from modifying it.
I modeled git_config_get_string() on the previously existing API function
git_config_string() with the signature,
int git_config_string(const char **dest, const char *var, const char *value).
But after writing this series I do think there isn't a good reason to
keep the constness in the new function also since the dest is given
its own copy.
strbuf_release(name);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-gui: Make git-gui lib dir configurable at runtime
Introduce the GIT_GUI_LIB_DIR environment variable, to tell git-gui
where to look for TCL libs. This allows a git-gui which has been
built with a prefix of /foo to be run out of directory /bar. This is
the equivalent of GIT_EXEC_PATH or GITPERLLIB but for git-gui's TCL
libraries.
Signed-off-by: David Turner dtur...@twitter.com
---
git-gui/Makefile | 3 ++-
git-gui/git-gui.sh | 6 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/git-gui/Makefile b/git-gui/Makefile
index cde8b2e..56bf9e2 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -177,7 +177,8 @@ git-gui: GIT-VERSION-FILE GIT-GUI-VARS
echo then $@+ \
echo ' 'echo \'git-gui version '$(GITGUI_VERSION)'\' $@+ \
echo else $@+ \
- echo ' 'exec \''$(libdir_SQ)/Git Gui.app/Contents/MacOS/$(subst
\,,$(TKEXECUTABLE))'\' \
+ echo ' libdir=$$(GIT_GUI_LIB_DIR:-$(libdir_SQ))' $@+ \
+ echo ' 'exec \'$$libdir/Git Gui.app/Contents/MacOS/$(subst
\,,$(TKEXECUTABLE))'\ \
'$$0 $$@' $@+ \
echo fi $@+ \
chmod +x $@+ \
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index b186329..6cbb36e 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -49,7 +49,11 @@ catch {rename send {}} ; # What an evil concept...
##
## locate our library
-set oguilib {@@GITGUI_LIBDIR@@}
+if { [info exists ::env(GIT_GUI_LIB_DIR) ] } {
+ set oguilib $::env(GIT_GUI_LIB_DIR)
+} else {
+ set oguilib {@@GITGUI_LIBDIR@@}
+}
set oguirel {@@GITGUI_RELATIVE@@}
if {$oguirel eq {1}} {
set oguilib [file dirname [file normalize $argv0]]
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/1] http: Add Accept-Language header if possible
Yi EungJun semtlen...@gmail.com writes:
From: Yi EungJun eungjun...@navercorp.com
Add an Accept-Language header which indicates the user's preferred
languages defined by $LANGUAGE, $LC_ALL, $LC_MESSAGES and $LANG.
Examples:
LANGUAGE= -
LANGUAGE=ko:en - Accept-Language: ko, en; q=0.9, *; q=0.1
LANGUAGE=ko LANG=en_US.UTF-8 - Accept-Language: ko, *; q=0.1
LANGUAGE= LANG=en_US.UTF-8 - Accept-Language: en-US, *; q=0.1
This gives git servers a chance to display remote error messages in
the user's preferred language.
Signed-off-by: Yi EungJun eungjun...@navercorp.com
---
http.c | 134
+
remote-curl.c | 2 +
t/t5550-http-fetch-dumb.sh | 31 +++
3 files changed, 167 insertions(+)
diff --git a/http.c b/http.c
index 3a28b21..ed4e8e1 100644
--- a/http.c
+++ b/http.c
@@ -67,6 +67,8 @@ static struct curl_slist *no_pragma_header;
static struct active_request_slot *active_queue_head;
+static struct strbuf *cached_accept_language = NULL;
Please drop = NULL that is unnecessary for BSS.
@@ -512,6 +514,9 @@ void http_cleanup(void)
cert_auth.password = NULL;
}
ssl_cert_password_required = 0;
+
+ if (cached_accept_language)
+ strbuf_release(cached_accept_language);
}
@@ -983,6 +988,129 @@ static void extract_content_type(struct strbuf *raw,
struct strbuf *type,
strbuf_addstr(charset, ISO-8859-1);
}
+/*
+ * Guess the user's preferred languages from the value in LANGUAGE
environment
+ * variable and LC_MESSAGES locale category.
+ *
+ * The result can be a colon-separated list like ko:ja:en.
+ */
+static const char *get_preferred_languages(void)
+{
+ const char *retval;
+
+ retval = getenv(LANGUAGE);
+ if (retval *retval)
+ return retval;
+
+ retval = setlocale(LC_MESSAGES, NULL);
+ if (retval *retval
+ strcmp(retval, C)
+ strcmp(retval, POSIX))
+ return retval;
+
+ return NULL;
+}
+
+/*
+ * Get an Accept-Language header which indicates user's preferred languages.
+ *
+ * Examples:
+ * LANGUAGE= -
+ * LANGUAGE=ko:en - Accept-Language: ko, en; q=0.9, *; q=0.1
+ * LANGUAGE=ko_KR.UTF-8:sr@latin - Accept-Language: ko-KR, sr; q=0.9, *;
q=0.1
+ * LANGUAGE=ko LANG=en_US.UTF-8 - Accept-Language: ko, *; q=0.1
+ * LANGUAGE= LANG=en_US.UTF-8 - Accept-Language: en-US, *; q=0.1
+ * LANGUAGE= LANG=C -
+ */
+static struct strbuf *get_accept_language(void)
+{
+ const char *lang_begin, *pos;
+ int q, max_q;
+ int num_langs;
+ int decimal_places;
+ int is_codeset_or_modifier = 0;
+ static struct strbuf buf = STRBUF_INIT;
+ struct strbuf q_format_buf = STRBUF_INIT;
+ char *q_format;
+
+ if (cached_accept_language)
+ return cached_accept_language;
+
+ lang_begin = get_preferred_languages();
+
+ /* Don't add Accept-Language header if no language is preferred. */
+ if (!(lang_begin *lang_begin)) {
It is not wrong per-se, but given how hard get_preferred_languages()
tries not to return a pointer to an empty string, this seems a bit
overly defensive to me.
+ cached_accept_language = buf;
+ return cached_accept_language;
It is somewhat unconventional to have a static pointer outside to
point at a singleton and then have a singleton actually as a static
structure. I would have done without buf in this function and
instead started this function like so:
if (cached_accept_language)
return cached_accept_language;
cached_accept_language = xmalloc(sizeof(struct strbuf));
strbuf_init(cached_accept_language, 0);
lang_begin = get_preferred_languages();
if (!lang_begin)
return cached_accept_language;
+ }
+
+ /* Count number of preferred lang_begin to decide precision of q-factor
*/
+ for (num_langs = 1, pos = lang_begin; *pos; pos++)
+ if (*pos == ':')
+ num_langs++;
+
+ /* Decide the precision for q-factor on number of preferred lang_begin.
*/
+ num_langs += 1; /* for '*' */
+ decimal_places = 1 + (num_langs 10) + (num_langs 100);
What if you got 6 languages ;-)? I do not think we want to bend
backwards and make the code list all 6 of them, assigning a
unique and decreasing q value to each of them, forming an overlong
Accept-Language header, but at the same time, I do not think we want
to show nonsense output because we compute the precision incorrectly
here.
+ strbuf_addf(q_format_buf, ; q=0.%%0%dd, decimal_places);
+ q_format = strbuf_detach(q_format_buf, NULL);
q_format_buf is an overkill use of strbuf, isn't it? Just
char q_format_buf[32];
sprintf(q_format_buf, ;q=0.%%0%d, decimal_places);
or something should be more than
Re: [PATCH v2 2/4] use strbuf_getcwd() to get the current working directory without fixed-sized buffers
Jeff King p...@peff.net writes:
On Sun, Jul 20, 2014 at 06:49:54PM +0200, René Scharfe wrote:
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 56f85e2..c4958b6 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -535,10 +535,10 @@ int cmd_init_db(int argc, const char **argv, const
char *prefix)
usage(init_db_usage[0]);
}
if (is_bare_repository_cfg == 1) {
-static char git_dir[PATH_MAX+1];
-
-setenv(GIT_DIR_ENVIRONMENT,
-getcwd(git_dir, sizeof(git_dir)), argc 0);
+struct strbuf cwd = STRBUF_INIT;
+strbuf_getcwd(cwd);
+setenv(GIT_DIR_ENVIRONMENT, cwd.buf, argc 0);
+strbuf_release(cwd);
Hmm. You are not making anything worse here, as we already do not check
the return value of getcwd. But what happens if it fails? Looks like we
currently get a segfault, and the new code will silently set the
variable to the empty string. Neither is particularly helpful.
Should we be using the xgetcwd helper that you add in the next patch?
-setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir,
sizeof(git_dir)), 0);
+strbuf_getcwd(cwd);
+setenv(GIT_DIR_ENVIRONMENT, cwd.buf, 0);
+strbuf_release(cwd);
Ditto here.
Good eyes.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH 4/6] t4210: skip command-line encoding tests on mingw
Am 21.07.2014 19:45, schrieb Johannes Schindelin: Hi Junio, On Mon, 21 Jul 2014, Junio C Hamano wrote: Oh by the way, can somebody remind me why we spell these as NOT_MINGW, instead of !MINGW? I guess that is my mistake; when I introduced the use of NOT_MINGW I was simply unaware of the !MINGW syntax. You can hardly be blamed. The first occurrence of NOT_MINGW was added much earlier than the ability to negate prerequisite tokens. Let's use the latter consistently? Of course! -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] t4210: skip command-line encoding tests on mingw
Junio C Hamano gits...@pobox.com writes: Oh by the way, can somebody remind me why we spell these as NOT_MINGW, instead of !MINGW? Simple answer seems to be that !ANYTHING appeared only at bdccd3c1 (test-lib: allow negation of prerequisites, 2012-11-14) but at that version already 5 test files use NOT_MINGW (and a few MINGW) as prerequisites. We can safely replace uses of NOT_MINGW prerequisite with !MINGW, it seems. Sorry for the noise. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/9] Add --graft option to git replace
Thanks, will replace and let's move it to 'next' this week. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] completion: add missing terminator in case statement
Junio C Hamano gits...@pobox.com writes: John Keeping j...@keeping.me.uk writes: Signed-off-by: John Keeping j...@keeping.me.uk --- As these ;; are separators not terminators, this is not strictly necessary. Squashing it into a change that adds more case arms to this case statement is of course not just good but necessary, though. s/necessary/may be /; if you add new arms before this one, you won't need it. But if you add one after this, you would ;-). contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 7a6e1d7..d0b2895 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1627,6 +1627,7 @@ _git_push () --repo) __gitcomp_nl $(__git_remotes) return +;; esac case $cur in --repo=*) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] git-gui: Make git-gui lib dir configurable at runime
Introduce the GIT_GUI_LIB_DIR environment variable, to tell git-gui
where to look for TCL libs. This allows a git-gui which has been
built with a prefix of /foo to be run out of directory /bar. This is
the equivalent of GIT_EXEC_PATH or GITPERLLIB but for git-gui's TCL
libraries.
Signed-off-by: David Turner dtur...@twitter.com
---
git-gui/Makefile | 3 ++-
git-gui/git-gui.sh | 6 +-
git-gui/macosx/AppMain.tcl | 7 ++-
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/git-gui/Makefile b/git-gui/Makefile
index cde8b2e..4f00bdd 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -177,7 +177,8 @@ git-gui: GIT-VERSION-FILE GIT-GUI-VARS
echo then $@+ \
echo ' 'echo \'git-gui version '$(GITGUI_VERSION)'\' $@+ \
echo else $@+ \
- echo ' 'exec \''$(libdir_SQ)/Git Gui.app/Contents/MacOS/$(subst
\,,$(TKEXECUTABLE))'\' \
+ echo ' libdir=$${GIT_GUI_LIB_DIR:-$(libdir_SQ)}' $@+ \
+ echo ' 'exec \'$$libdir/Git Gui.app/Contents/MacOS/$(subst
\,,$(TKEXECUTABLE))'\ \
'$$0 $$@' $@+ \
echo fi $@+ \
chmod +x $@+ \
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index b186329..6cbb36e 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -49,7 +49,11 @@ catch {rename send {}} ; # What an evil concept...
##
## locate our library
-set oguilib {@@GITGUI_LIBDIR@@}
+if { [info exists ::env(GIT_GUI_LIB_DIR) ] } {
+ set oguilib $::env(GIT_GUI_LIB_DIR)
+} else {
+ set oguilib {@@GITGUI_LIBDIR@@}
+}
set oguirel {@@GITGUI_RELATIVE@@}
if {$oguirel eq {1}} {
set oguilib [file dirname [file normalize $argv0]]
diff --git a/git-gui/macosx/AppMain.tcl b/git-gui/macosx/AppMain.tcl
index 738bdd0..b6c6dc3 100644
--- a/git-gui/macosx/AppMain.tcl
+++ b/git-gui/macosx/AppMain.tcl
@@ -1,5 +1,10 @@
set gitexecdir {@@gitexecdir@@}
-set gitguilib {@@GITGUI_LIBDIR@@}
+if { [info exists ::env(GIT_GUI_LIB_DIR) ] } {
+ set gitguilib $::env(GIT_GUI_LIB_DIR)
+} else {
+ set gitguilib {@@GITGUI_LIBDIR@@}
+}
+
set env(PATH) $gitexecdir:$env(PATH)
if {[string first -psn [lindex $argv 0]] == 0} {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Git + mod_auth_kerb
Hello, We are currently working on a single sign on setup for our git install. We are using git 2.0.2 (ubuntu) plus apache/2.2.22 mod_auth_kerb on the server side. Here some scenario we are trying to accomplish : -Without Kerberos ticket stored. Git ask for username/password. Result = Authentication failed -Kerberos ticket in store and BAD password : Git ask for username/password. Result = Authentication failed -Kerberos ticket in Store entering good password : Git ask for username/password. Result = Authentication failed on some host, other works -Kerberos ticket in Store and embedding the username in the URI (aka https://username@repo) Git don't ask for anything or ask for password Result = Works on some host, other request the password. (Will fail if the kerberos ticket not in store) This is a very strange behaviour. It seems to be cause by the way libcurl and git interact and the way the authentication goes (Negociate first, then basic auth). I have tried to use the helper to store invalid authentication information. With not much success. Any idea ? Thanks, JF -- Avis de confidentialité Les informations contenues dans le présent message et dans toute pièce qui lui est jointe sont confidentielles et peuvent être protégées par le secret professionnel. Ces informations sont à l’usage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s’il vous plait communiquer immédiatement avec l’expéditeur et en détruire tout exemplaire. De plus, il vous est strictement interdit de le divulguer, de le distribuer ou de le reproduire sans l’autorisation de l’expéditeur. Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential information which may be privileged and which is intended for the exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or copying of this message and/or any attachment hereto without the consent of the sender is strictly prohibited. Thank you. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-gui: Make git-gui lib dir configurable at runtime
David Turner dtur...@twopensource.com writes:
Introduce the GIT_GUI_LIB_DIR environment variable, to tell git-gui
where to look for TCL libs. This allows a git-gui which has been
built with a prefix of /foo to be run out of directory /bar. This is
the equivalent of GIT_EXEC_PATH or GITPERLLIB but for git-gui's TCL
libraries.
Signed-off-by: David Turner dtur...@twitter.com
---
git-gui/Makefile | 3 ++-
git-gui/git-gui.sh | 6 +-
2 files changed, 7 insertions(+), 2 deletions(-)
Would a similar change to gitk necessary/beneficial to platforms
that would benefit from this change?
git-gui directory in my tree comes from its upstream repository
git://repo.or.cz/git-gui.git/, and it is maintained by Pat Thoyts
(Cc'ed).
gitk is from git://ozlabs.org/~paulus/gitk.git maintained by Paul
Mackerras pau...@samba.org (not Cc'ed).
Note that these two upstream projects do not have leading
directories git-gui and gitk-git themselves (they are merged to my
tree while their paths being renamed). A patch that is appliable to
them would touch paths without them (e.g. Makefile and git-gui.sh
for an equivalent of the patch I am responding to).
Thanks.
diff --git a/git-gui/Makefile b/git-gui/Makefile
index cde8b2e..56bf9e2 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -177,7 +177,8 @@ git-gui: GIT-VERSION-FILE GIT-GUI-VARS
echo then $@+ \
echo ' 'echo \'git-gui version '$(GITGUI_VERSION)'\' $@+ \
echo else $@+ \
- echo ' 'exec \''$(libdir_SQ)/Git Gui.app/Contents/MacOS/$(subst
\,,$(TKEXECUTABLE))'\' \
+ echo ' libdir=$$(GIT_GUI_LIB_DIR:-$(libdir_SQ))' $@+ \
+ echo ' 'exec \'$$libdir/Git Gui.app/Contents/MacOS/$(subst
\,,$(TKEXECUTABLE))'\ \
'$$0 $$@' $@+ \
echo fi $@+ \
chmod +x $@+ \
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index b186329..6cbb36e 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -49,7 +49,11 @@ catch {rename send {}} ; # What an evil concept...
##
## locate our library
-set oguilib {@@GITGUI_LIBDIR@@}
+if { [info exists ::env(GIT_GUI_LIB_DIR) ] } {
+ set oguilib $::env(GIT_GUI_LIB_DIR)
+} else {
+ set oguilib {@@GITGUI_LIBDIR@@}
+}
set oguirel {@@GITGUI_RELATIVE@@}
if {$oguirel eq {1}} {
set oguilib [file dirname [file normalize $argv0]]
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-gui: Make git-gui lib dir configurable at runtime
On Mon, 2014-07-21 at 14:06 -0700, Junio C Hamano wrote: David Turner dtur...@twopensource.com writes: Introduce the GIT_GUI_LIB_DIR environment variable, to tell git-gui where to look for TCL libs. This allows a git-gui which has been built with a prefix of /foo to be run out of directory /bar. This is the equivalent of GIT_EXEC_PATH or GITPERLLIB but for git-gui's TCL libraries. Signed-off-by: David Turner dtur...@twitter.com --- git-gui/Makefile | 3 ++- git-gui/git-gui.sh | 6 +- 2 files changed, 7 insertions(+), 2 deletions(-) Would a similar change to gitk necessary/beneficial to platforms that would benefit from this change? Apparently not; it seems to work fine for me from an alternate location. Convenient! git-gui directory in my tree comes from its upstream repository git://repo.or.cz/git-gui.git/, and it is maintained by Pat Thoyts (Cc'ed). Note that these two upstream projects do not have leading directories git-gui and gitk-git themselves (they are merged to my tree while their paths being renamed). A patch that is appliable to them would touch paths without them (e.g. Makefile and git-gui.sh for an equivalent of the patch I am responding to). Pat, do you want patches via the git mailing list, personal mail, or some other way? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] t4210: skip command-line encoding tests on mingw
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
Oh by the way, can somebody remind me why we spell these as
NOT_MINGW, instead of !MINGW?
Simple answer seems to be that !ANYTHING appeared only at bdccd3c1
(test-lib: allow negation of prerequisites, 2012-11-14) but at that
version already 5 test files use NOT_MINGW (and a few MINGW) as
prerequisites. We can safely replace uses of NOT_MINGW prerequisite
with !MINGW, it seems.
Sorry for the noise.
So here is the first of the two small/trivial patch series.
To prepare the first one, I did git grep -e '\NOT_' t/ to the
result of applying Stepan's series and edited the hits manually.
And then compared the result with running
$ perl -p -i -e 'if (!/\btest_set_prereq\s/) {
s/\bNOT_([A-Z]*)\b/!$1/g
}' t/t*.sh
on Stepan's series to see if I missed anything.
The second one was discovered while doing the manual fix mentioned
above.
-- 8 --
Subject: [PATCH 1/2] test prerequisites: eradicate NOT_FOO
Support for Back when bdccd3c1 (test-lib: allow negation of
prerequisites, 2012-11-14) introduced negated predicates
(e.g. !MINGW,!CYGWIN), we already had 5 test files that use
NOT_MINGW (and a few MINGW) as prerequisites.
Let's not add NOT_FOO and rewrite existing ones as !FOO for both
MINGW and CYGWIN.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t0008-ignores.sh| 2 +-
t/t0081-line-buffer.sh| 2 +-
t/t1020-subdirectory.sh | 2 +-
t/t1300-repo-config.sh| 6 +++---
t/t1402-check-ref-format.sh | 32
t/t3901-i18n-patch.sh | 10 +-
t/t4201-shortlog.sh | 6 +++---
t/t4210-log-i18n.sh | 4 ++--
t/t5601-clone.sh | 4 ++--
t/t8005-blame-i18n.sh | 8
t/t9300-fast-import.sh| 8
t/t9809-git-p4-client-view.sh | 4 ++--
t/t9812-git-p4-wildcards.sh | 14 +++---
t/t9815-git-p4-submit-fail.sh | 2 +-
t/test-lib.sh | 4
15 files changed, 52 insertions(+), 56 deletions(-)
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index 39e55a1..8dc6939 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -806,7 +806,7 @@ test_expect_success !MINGW 'quoting allows trailing
whitespace' '
test_cmp err.expect err
'
-test_expect_success NOT_MINGW,NOT_CYGWIN 'correct handling of backslashes' '
+test_expect_success !MINGW,!CYGWIN 'correct handling of backslashes' '
rm -rf whitespace
mkdir whitespace
whitespace/trailing 1
diff --git a/t/t0081-line-buffer.sh b/t/t0081-line-buffer.sh
index 25dba00..ce92e6a 100755
--- a/t/t0081-line-buffer.sh
+++ b/t/t0081-line-buffer.sh
@@ -29,7 +29,7 @@ test_expect_success '0-length read, send along greeting' '
test_cmp expect actual
'
-test_expect_success NOT_MINGW 'read from file descriptor' '
+test_expect_success !MINGW 'read from file descriptor' '
rm -f input
echo hello expect
echo hello input
diff --git a/t/t1020-subdirectory.sh b/t/t1020-subdirectory.sh
index 62c0d25..2edb4f2 100755
--- a/t/t1020-subdirectory.sh
+++ b/t/t1020-subdirectory.sh
@@ -118,7 +118,7 @@ test_expect_success 'alias expansion' '
)
'
-test_expect_success NOT_MINGW '!alias expansion' '
+test_expect_success !MINGW '!alias expansion' '
pwd expect
(
git config alias.test-alias-directory !pwd
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 3f80ff0..fb871d0 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -824,14 +824,14 @@ cat expect \EOF
trailingtilde = foo~
EOF
-test_expect_success NOT_MINGW 'set --path' '
+test_expect_success !MINGW 'set --path' '
rm -f .git/config
git config --path path.home ~/
git config --path path.normal /dev/null
git config --path path.trailingtilde foo~
test_cmp expect .git/config'
-if test_have_prereq NOT_MINGW test ${HOME+set}
+if test_have_prereq !MINGW test ${HOME+set}
then
test_set_prereq HOMEVAR
fi
@@ -854,7 +854,7 @@ cat expect \EOF
foo~
EOF
-test_expect_success NOT_MINGW 'get --path copes with unset $HOME' '
+test_expect_success !MINGW 'get --path copes with unset $HOME' '
(
unset HOME;
test_must_fail git config --get --path path.home \
diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
index 9aeb352..72fd917 100755
--- a/t/t1402-check-ref-format.sh
+++ b/t/t1402-check-ref-format.sh
@@ -30,17 +30,17 @@ invalid_ref() {
}
invalid_ref ''
-invalid_ref NOT_MINGW '/'
-invalid_ref NOT_MINGW '/' --allow-onelevel
-invalid_ref NOT_MINGW '/' --normalize
-invalid_ref NOT_MINGW '/' '--allow-onelevel --normalize'
+invalid_ref !MINGW '/'
+invalid_ref !MINGW '/' --allow-onelevel
+invalid_ref !MINGW '/' --normalize
+invalid_ref !MINGW '/' '--allow-onelevel --normalize'
valid_ref 'foo/bar/baz'
valid_ref
[PATCH 2/2] test prerequisites: enumerate with commas
test_have_prereq does understand multiple predicates given as separate arguments, but that is by accident. We should list the prerequisites just like we use them as the (first) optional parameter for test_expect_success, concatenated with commas, for consistency. Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t9809-git-p4-client-view.sh | 4 ++-- t/t9812-git-p4-wildcards.sh | 14 +++--- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/t/t9809-git-p4-client-view.sh b/t/t9809-git-p4-client-view.sh index e80db7a..897b3c3 100755 --- a/t/t9809-git-p4-client-view.sh +++ b/t/t9809-git-p4-client-view.sh @@ -365,7 +365,7 @@ test_expect_success 'wildcard files submit back to p4, client-spec case' ' ( cd $git echo git-wild-hash dir1/git-wild#hash - if test_have_prereq !MINGW !CYGWIN + if test_have_prereq !MINGW,!CYGWIN then echo git-wild-star dir1/git-wild\*star fi @@ -379,7 +379,7 @@ test_expect_success 'wildcard files submit back to p4, client-spec case' ' ( cd $cli test_path_is_file dir1/git-wild#hash - if test_have_prereq !MINGW !CYGWIN + if test_have_prereq !MINGW,!CYGWIN then test_path_is_file dir1/git-wild\*star fi diff --git a/t/t9812-git-p4-wildcards.sh b/t/t9812-git-p4-wildcards.sh index ed4b488..0206771 100755 --- a/t/t9812-git-p4-wildcards.sh +++ b/t/t9812-git-p4-wildcards.sh @@ -14,7 +14,7 @@ test_expect_success 'add p4 files with wildcards in the names' ' printf file2\nhas\nsome\nrandom\ntext\n file2 p4 add file2 echo file-wild-hash file-wild#hash - if test_have_prereq !MINGW !CYGWIN + if test_have_prereq !MINGW,!CYGWIN then echo file-wild-star file-wild\*star fi @@ -31,7 +31,7 @@ test_expect_success 'wildcard files git p4 clone' ' ( cd $git test -f file-wild#hash - if test_have_prereq !MINGW !CYGWIN + if test_have_prereq !MINGW,!CYGWIN then test -f file-wild\*star fi @@ -46,7 +46,7 @@ test_expect_success 'wildcard files submit back to p4, add' ' ( cd $git echo git-wild-hash git-wild#hash - if test_have_prereq !MINGW !CYGWIN + if test_have_prereq !MINGW,!CYGWIN then echo git-wild-star git-wild\*star fi @@ -60,7 +60,7 @@ test_expect_success 'wildcard files submit back to p4, add' ' ( cd $cli test_path_is_file git-wild#hash - if test_have_prereq !MINGW !CYGWIN + if test_have_prereq !MINGW,!CYGWIN then test_path_is_file git-wild\*star fi @@ -75,7 +75,7 @@ test_expect_success 'wildcard files submit back to p4, modify' ' ( cd $git echo new-line git-wild#hash - if test_have_prereq !MINGW !CYGWIN + if test_have_prereq !MINGW,!CYGWIN then echo new-line git-wild\*star fi @@ -89,7 +89,7 @@ test_expect_success 'wildcard files submit back to p4, modify' ' ( cd $cli test_line_count = 2 git-wild#hash - if test_have_prereq !MINGW !CYGWIN + if test_have_prereq !MINGW,!CYGWIN then test_line_count = 2 git-wild\*star fi @@ -152,7 +152,7 @@ test_expect_success 'wildcard files submit back to p4, delete' ' ( cd $cli test_path_is_missing git-wild#hash - if test_have_prereq !MINGW !CYGWIN + if test_have_prereq !MINGW,!CYGWIN then test_path_is_missing git-wild\*star fi -- 2.0.2-870-g9e2e527 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] t4210: skip command-line encoding tests on mingw
Junio C Hamano gits...@pobox.com writes:
So here is the first of the two small/trivial patch series.
To prepare the first one, I did git grep -e '\NOT_' t/ to the
result of applying Stepan's series and edited the hits manually.
And then compared the result with running
$ perl -p -i -e 'if (!/\btest_set_prereq\s/) {
s/\bNOT_([A-Z]*)\b/!$1/g
}' t/t*.sh
on Stepan's series to see if I missed anything.
The second one was discovered while doing the manual fix mentioned
above.
...
t/t1402-check-ref-format.sh | 32
t/test-lib.sh | 4
15 files changed, 52 insertions(+), 56 deletions(-)
Unfortunately, t1402 needs more work X-.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: fix missing text for rev-parse --verify
The caret (^) is used as a markup symbol in AsciiDoc. Due to the
inability of AsciiDoc to parse a line containing an unmatched caret, it
omitted the line from the output, resulting in the man page missing the
end of a sentence. Escape this caret so that the man page ends up with
the complete text.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
Documentation/git-rev-parse.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 9bd76a5..0b84769 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -102,7 +102,7 @@ eval set -- $(git rev-parse --sq --prefix $prefix $@)
+
If you want to make sure that the output actually names an object in
your object database and/or can be used as a specific type of object
-you require, you can add ^{type} peeling operator to the parameter.
+you require, you can add \^{type} peeling operator to the parameter.
For example, `git rev-parse $VAR^{commit}` will make sure `$VAR`
names an existing object that is a commit-ish (i.e. a commit, or an
annotated tag that points at a commit). To make sure that `$VAR`
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: fix missing text for rev-parse --verify
brian m. carlson wrote:
The caret (^) is used as a markup symbol in AsciiDoc. Due to the
inability of AsciiDoc to parse a line containing an unmatched caret, it
omitted the line from the output, resulting in the man page missing the
end of a sentence.
Wow. Usually asciidoc is more forgiving than that. Are there other
pages affected by this too (e.g., the commit HEAD^ in
user-manual.txt)?
[...]
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -102,7 +102,7 @@ eval set -- $(git rev-parse --sq --prefix $prefix
$@)
+
If you want to make sure that the output actually names an object in
your object database and/or can be used as a specific type of object
-you require, you can add ^{type} peeling operator to the parameter.
+you require, you can add \^{type} peeling operator to the parameter.
Does using {caret} for ^ work, too? Generally in asciidoc using a
backslash to escape delimiter characters leads to trouble when the
number of delimiters changes or the text is copy+pasted, since in a
context where the backslash is unneeded it ends up being rendered as a
literal backslash.
Alternatively, does `^{type}` work?
Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git + mod_auth_kerb
On Mon, Jul 21, 2014 at 05:06:50PM -0400, Jean-Francois Bouchard wrote: Hello, We are currently working on a single sign on setup for our git install. We are using git 2.0.2 (ubuntu) plus apache/2.2.22 mod_auth_kerb on the server side. Here some scenario we are trying to accomplish : -Without Kerberos ticket stored. Git ask for username/password. Result = Authentication failed -Kerberos ticket in store and BAD password : Git ask for username/password. Result = Authentication failed -Kerberos ticket in Store entering good password : Git ask for username/password. Result = Authentication failed on some host, other works -Kerberos ticket in Store and embedding the username in the URI (aka https://username@repo) Git don't ask for anything or ask for password Result = Works on some host, other request the password. (Will fail if the kerberos ticket not in store) So git uses libcurl with CURLAUTH_ANY. In order for authentication to work with libcurl, you have to supply a username. If you specify it in the URL, the libcurl realizes that it can use Kerberos, and goes on its merry way. If you don't specify the username in the URL, git notices that authentication has failed, and asks the credential store for a username and password. git does not know that a password is not needed, so the credential subsystem prompts for one anyway. I have mod_auth_kerb set up against Apache 2.4.9 at the moment, although I've used 2.2 before. I always use a username in the URL, and if I get prompted for the password, I just Ctrl-C out and run kinit before pushing again. I don't have mod_auth_kerb set up to fall back to basic auth, but if you do, using a username and password should work properly. You can use set the environment variable GIT_CURL_VERBOSE to 1 to see more information about what's actually going over the wire. This is a very strange behaviour. It seems to be cause by the way libcurl and git interact and the way the authentication goes (Negociate first, then basic auth). I have tried to use the helper to store invalid authentication information. With not much success. libcurl will always prefer something (anything) over basic auth, since basic auth is completely insecure unless you're using HTTPS. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH] Documentation: fix missing text for rev-parse --verify
On Mon, Jul 21, 2014 at 04:14:38PM -0700, Jonathan Nieder wrote:
brian m. carlson wrote:
The caret (^) is used as a markup symbol in AsciiDoc. Due to the
inability of AsciiDoc to parse a line containing an unmatched caret, it
omitted the line from the output, resulting in the man page missing the
end of a sentence.
Wow. Usually asciidoc is more forgiving than that. Are there other
pages affected by this too (e.g., the commit HEAD^ in
user-manual.txt)?
I didn't look at any other pages before submitting this. I noticed when
I was looking up git rev-parse --verify on my Debian sid laptop at work.
I just looked, and the place you mentioned in user-manual.txt wasn't
affected. It looks like this is the only place in running text that we
don't use backticks around the caret-containing text.
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -102,7 +102,7 @@ eval set -- $(git rev-parse --sq --prefix $prefix
$@)
+
If you want to make sure that the output actually names an object in
your object database and/or can be used as a specific type of object
-you require, you can add ^{type} peeling operator to the parameter.
+you require, you can add \^{type} peeling operator to the parameter.
Does using {caret} for ^ work, too? Generally in asciidoc using a
backslash to escape delimiter characters leads to trouble when the
number of delimiters changes or the text is copy+pasted, since in a
context where the backslash is unneeded it ends up being rendered as a
literal backslash.
{caret} does not work; it leaves the sentence broken still. `^{type}`
does work. Since that seems a bit cleaner, and I think the resultant
formatting is fine, I'll reroll with that change.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
Same last name 8.15 am
Dear. Friend, I am Vice Chairman, Board of Directors Hang Seng Bank Hong Kong. Dr.Raymond Chien; A deceased client of mine, that shares the same last name as yours, Died without a next of kin. $16,M in my Branch. Contact Email: drhraymo...@yahoo.com.hk Regards, Dr Raymond. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
