Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`
Junio C Hamano gits...@pobox.com writes: in my ~/.gitconfig and then for a particular project I wanted to use a custom pattern in its .git/config but it was sufficient to define the pattern without using extended regexp, I would be tempted to say diff.foo.funcname Wine$ The point is: to do that, you need to know that funcname exists, hence read archives of the doc before 2008 (it disapeared in 45d9414fa5599b41578625961b53e18a9b9148c7) or read the code. And if I read correctly the commit message for the commit, funcname is not portable so you should use xfuncname anyway. The real reason for this change is to let the code work with the new git_config, but I think it's reasonable not to bother with the original behavior for a feature deprecated so long ago. That said, I think the commit message should be improved (recall the drawbacks of funcname). -- 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 2/7] rewrite git_config() to use the config-set API
Junio C Hamano gits...@pobox.com writes:
+int git_config(config_fn_t fn, void *data)
+{
+git_config_check_init();
+return configset_iter(the_config_set, fn, data);
+}
Perhaps if you define this function at the right place in the file
you do not have to add an forward decl of git_config_check_init()?
OTOH, having git_config right next to git_config_raw and configset_iter
is a good thing, and keeping git_config_raw where git_config used to be
seems logical.
--
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 3/5] checkout --to: no auto-detach if the ref is already checked out
On Wed, Jul 23, 2014 at 8:48 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: Nguyễn Thái Ngọc Duy venit, vidit, dixit 23.07.2014 13:43: + if (advice_checkout_to) + die(_(%s is already checked out at %s.\n + Either use --detach or -b together with --to + or switch branch in the the other checkout.), or switch to a different branch in the other checkout. But maybe we can be even more helpful, like: %s is already checked out at %s.\n Either checkout the detached head of branch %s using\n git checkout --detach --to %s %s\n or checkout a new branch based off %s using\n git checkout --to %s -b %s newbranch %s\n or switch to a different branch in the other checkout. if we can figure out the appropriate arguments at this point in the code. We would not be able to construct the exact command that the user has entered, so perhaps git checkout --detach more options %s git checkout -b new branch more options %s ? Note that this does not only occur when --to is given. If you have two checkouts associated to the same repo, git checkout foo on one checkout when foo is held by another checkout would cause the same error. I'll need to think of a better name than advice.checkoutTo. -- 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 3/5] checkout --to: no auto-detach if the ref is already checked out
On Thu, Jul 24, 2014 at 4:16 AM, Junio C Hamano gits...@pobox.com wrote:
+ if (strbuf_read_file(sb, path.buf, 0) = 0 ||
+ !skip_prefix(sb.buf, ref:, start))
+ goto done;
while (isspace(*start))
start++;
end = start;
while (*end !isspace(*end))
end++;
Not new in this round of update, and may not even be an issue, but:
- Earlier, the code returned early on a negative return value from
read-file (i.e., an error), but this round it also does so for
zero. Intended?
Yes. But it does not make any difference. strbuf_read_file returns
sb.len, if it's empty, the next skip_prefix would fail anyway.
- The above duplicates the logic in resolve_ref_unsafe() and
resolve_gitlink_ref_recursive(); three places now knows what a
textual symref looks like (i.e. begins with ref:, zero or more
whitespaces, the target ref and then zero or more trailing
whitespaces). Perhaps we need to consolidate the code further,
so that this knowledge does not leak out of refs.c?
OK. Will do (unless Mike has a different opinion about this).
+ if (strncmp(start, new-path, end - start) ||
+ new-path[end - start] != '\0')
+ goto done;
+ if (id) {
+ strbuf_reset(path);
+ strbuf_addf(path, %s/repos/%s/gitdir,
+ get_git_common_dir(), id);
+ if (strbuf_read_file(gitdir, path.buf, 0) = 0)
+ goto done;
+ while (gitdir.len (gitdir.buf[gitdir.len - 1] == '\n' ||
+ gitdir.buf[gitdir.len - 1] == '\r'))
+ gitdir.buf[--gitdir.len] = '\0';
Accepting arbitrary numbers of '\r' and '\n' sounds as if the code
is allowing it, but text editors would not end their files with a
nonsense sequence like \r\r\n\r unless the end-user works to do
so, and if you are prepared to be lenient to noisy human input, not
trimming trailing whitespaces does not look it is going far enough
to help them.
I do not see a good reason to allow random text editors to edit this
file in the first place, so my preference is:
if (strbuf_read_file(...) 0 ||
gitdir.len == 0 ||
gitdir.buf[gitdir.len - 1] != '\n')
goto error_return;
gitdir.buf[--gitdir.len] = '\0';
Alternatively, if you are trying to be lenient to human input, I
would understand:
if (strbuf_read_file(...) 0)
goto error_return;
strbuf_rtrim(gitdir);
The code in the patch, which is something in between, does not make
much sense to me.
I think more about echo abc $this_file where the echo command may
output '\r\n' on Windows (wild guess though, I don't use Windows
much). I think I'm going with _rtrim.
--
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 2/5] prune --repos: fix uninitialized access
On Thu, Jul 24, 2014 at 2:59 AM, Junio C Hamano gits...@pobox.com wrote: It does not explain what the change to the test is about, though. The old test and code are wrong. We want to verify repos are not pruned if they're new (like, just created). But git prune without --expire sets expire time to 0x (everything will be pruned) so today's repos are pruned as well. But the old code is wrong. It returns 0 at the end of prune_repo_dir instead of1, so st.st_mtime is never checked, the repos are not pruned. The end result is an incorrect passed test :( -- 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 1/7] config.c: fix accuracy of line number in errors
On 7/24/2014 3:19 AM, Junio C Hamano wrote: Tanay Abhra tanay...@gmail.com writes: If a callback returns a negative value to `git_config*()` family, they call `die()` while printing the line number and the file name. Currently the printed line number is off by one, thus printing the wrong line number. Make `linenr` point to the line we just parsed during the call to callback to get accurate line number in error messages. Discovered-by: Tanay Abhra tanay...@gmail.com Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr Thanks. I am not sure what to read in these two lines. Was the fix done by you or Matthieu? I misunderstood the meaning of the message trailers. I will correct it in the next re roll. -- 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 3/7] add a test for semantic errors in config files
On 7/24/2014 3:41 AM, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Tanay Abhra tanay...@gmail.com writes: +test_expect_success 'check line errors for malformed values' ' + cp .git/config .git/config.old Should this be mv not cp? You will be overwriting the file from scratch in the later part of this test. Noted. + test_when_finished mv .git/config.old .git/config + echo [alias]\n br .git/config Is the use of \n portable? Yes, you are right, will replace with printf in the next 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 3/7] add a test for semantic errors in config files
Tanay Abhra tanay...@gmail.com writes: + test_when_finished mv .git/config.old .git/config + echo [alias]\n br .git/config Is the use of \n portable? Yes, you are right, will replace with printf in the next patch. ... or a cat .git/config \EOF, since this is the construct used elsewhere in the script. -- 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: `ab | (cd cd git apply -)' fails with v2.0.0
Steffen Nurpmeso venit, vidit, dixit 24.07.2014 15:29: Hello (again, psst, after a long time), it happened yesterday that i needed to do $ git diff HEAD:FILE COMMIT:SAME-FILE | (cd src git apply -) but found that didn't work with v2.0.0 (silently succeeds?, doing nothing). It works without the subshell and the cd(1); i had to use `(cd src patch -p2)' instead to keep in going. Just in case that is not known yet (i've updated my git(1) repo, but in the 1466 commits in between nothing sprung into my eye regarding apply, and a Gmane search didn't, too). No need to Cc: me, please just fix it; thank you. Ciao, --steffen Ah little more context would help. Are you diffing files in the subdir src, or a file at the root which happens to be present in the subdir src as well? 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
`ab | (cd cd git apply -)' fails with v2.0.0
Hello (again, psst, after a long time), it happened yesterday that i needed to do $ git diff HEAD:FILE COMMIT:SAME-FILE | (cd src git apply -) but found that didn't work with v2.0.0 (silently succeeds?, doing nothing). It works without the subshell and the cd(1); i had to use `(cd src patch -p2)' instead to keep in going. Just in case that is not known yet (i've updated my git(1) repo, but in the 1466 commits in between nothing sprung into my eye regarding apply, and a Gmane search didn't, too). No need to Cc: me, please just fix it; thank you. Ciao, --steffen -- 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 0/7] Rewrite `git_config()` using config-set API
Are you done with the original series, or do you still want to fix
the const-ness issue with the string pointer before working on
follow-up topics like this one?
I am attaching the v12 with two new functions git_configset_get_string()
git_configset_get_string_const().
Diff between v11 and v12 is appended below for easy review.
-- 8 --
diff --git a/Documentation/technical/api-config.txt
b/Documentation/technical/api-config.txt
index 8a86e45..815c1ee 100644
--- a/Documentation/technical/api-config.txt
+++ b/Documentation/technical/api-config.txt
@@ -138,13 +138,18 @@ as well as retrieval for the queried variable, including:
Similar to `git_config_get_bool`, except that it returns -1 on error
rather than dying.
-`int git_config_get_string(const char *key, const char **dest)`::
+`int git_config_get_string_const(const char *key, const char **dest)`::
Allocates and copies the retrieved string into the `dest` parameter for
the configuration variable `key`; if NULL string is given, prints an
error message and returns -1. When the configuration variable `key` is
not found, returns 1 without touching `dest`.
+`int git_config_get_string(const char *key, char **dest)`::
+
+ Similar to `git_config_get_string_const`, except that retrieved value
+ copied into the `dest` parameter is a mutable string.
+
`int git_config_get_pathname(const char *key, const char **dest)`::
Similar to `git_config_get_string`, but expands `~` or `~user` into
diff --git a/cache.h b/cache.h
index 2f63fd1..7292aef 100644
--- a/cache.h
+++ b/cache.h
@@ -1361,7 +1361,8 @@ extern int git_configset_add_file(struct config_set *cs,
const char *filename);
extern int git_configset_get_value(struct config_set *cs, const char *key,
const char **value);
extern const struct string_list *git_configset_get_value_multi(struct
config_set *cs, const char *key);
extern void git_configset_clear(struct config_set *cs);
-extern int git_configset_get_string(struct config_set *cs, const char *key,
const char **dest);
+extern int git_configset_get_string_const(struct config_set *cs, const char
*key, const char **dest);
+extern int git_configset_get_string(struct config_set *cs, const char *key,
char **dest);
extern int git_configset_get_int(struct config_set *cs, const char *key, int
*dest);
extern int git_configset_get_ulong(struct config_set *cs, const char *key,
unsigned long *dest);
extern int git_configset_get_bool(struct config_set *cs, const char *key, int
*dest);
@@ -1373,7 +1374,8 @@ extern int git_config_get_value(const char *key, const
char **value);
extern const struct string_list *git_config_get_value_multi(const char *key);
extern void git_config_clear(void);
extern void git_config_iter(config_fn_t fn, void *data);
-extern int git_config_get_string(const char *key, const char **dest);
+extern int git_config_get_string_const(const char *key, const char **dest);
+extern int git_config_get_string(const char *key, char **dest);
extern int git_config_get_int(const char *key, int *dest);
extern int git_config_get_ulong(const char *key, unsigned long *dest);
extern int git_config_get_bool(const char *key, int *dest);
diff --git a/config.c b/config.c
index 22971e9..0d799e0 100644
--- a/config.c
+++ b/config.c
@@ -1332,7 +1332,7 @@ const struct string_list
*git_configset_get_value_multi(struct config_set *cs, c
return e ? e-value_list : NULL;
}
-int git_configset_get_string(struct config_set *cs, const char *key, const
char **dest)
+int git_configset_get_string_const(struct config_set *cs, const char *key,
const char **dest)
{
const char *value;
if (!git_configset_get_value(cs, key, value))
@@ -1341,6 +1341,19 @@ int git_configset_get_string(struct config_set *cs,
const char *key, const char
return 1;
}
+int git_configset_get_string(struct config_set *cs, const char *key, char
**dest)
+{
+ const char *value;
+ if (!git_configset_get_value(cs, key, value)) {
+ if (!value)
+ return config_error_nonbool(key);
+ *dest = xstrdup(value);
+ return 0;
+ }
+ else
+ return 1;
+}
+
int git_configset_get_int(struct config_set *cs, const char *key, int *dest)
{
const char *value;
@@ -1430,7 +1443,13 @@ const struct string_list
*git_config_get_value_multi(const char *key)
return git_configset_get_value_multi(the_config_set, key);
}
-int git_config_get_string(const char *key, const char **dest)
+int git_config_get_string_const(const char *key, const char **dest)
+{
+ git_config_check_init();
+ return git_configset_get_string_const(the_config_set, key, dest);
+}
+
+int git_config_get_string(const char *key, char **dest)
{
git_config_check_init();
return git_configset_get_string(the_config_set, key, dest);
-- 8 --
--
To unsubscribe from this list: send the line unsubscribe git
[PATCH v12 1/2] add `config_set` API for caching config-like files
Currently `git_config()` uses a callback mechanism and file rereads for config values. Due to this approach, it is not uncommon for the config files to be parsed several times during the run of a git program, with different callbacks picking out different variables useful to themselves. Add a `config_set`, that can be used to construct an in-memory cache for config-like files that the caller specifies (i.e., files like `.gitmodules`, `~/.gitconfig` etc.). Add two external functions `git_configset_get_value` and `git_configset_get_value_multi` for querying from the config sets. `git_configset_get_value` follows `last one wins` semantic (i.e. if there are multiple matches for the queried key in the files of the configset the value returned will be the last entry in `value_list`). `git_configset_get_value_multi` returns a list of values sorted in order of increasing priority (i.e. last match will be at the end of the list). Add type specific query functions like `git_configset_get_bool` and similar. Add a default `config_set`, `the_config_set` to cache all key-value pairs read from usual config files (repo specific .git/config, user wide ~/.gitconfig, XDG config and the global /etc/gitconfig). `the_config_set` is populated using `git_config()`. Add two external functions `git_config_get_value` and `git_config_get_value_multi` for querying in a non-callback manner from `the_config_set`. Also, add type specific query functions that are implemented as a thin wrapper around the `config_set` API. Signed-off-by: Matthieu Moy matthieu@imag.fr Signed-off-by: Tanay Abhra tanay...@gmail.com --- Documentation/technical/api-config.txt | 142 + cache.h| 32 config.c | 282 + setup.c| 9 ++ 4 files changed, 465 insertions(+) diff --git a/Documentation/technical/api-config.txt b/Documentation/technical/api-config.txt index 230b3a0..815c1ee 100644 --- a/Documentation/technical/api-config.txt +++ b/Documentation/technical/api-config.txt @@ -77,6 +77,86 @@ To read a specific file in git-config format, use `git_config_from_file`. This takes the same callback and data parameters as `git_config`. +Querying For Specific Variables +--- + +For programs wanting to query for specific variables in a non-callback +manner, the config API provides two functions `git_config_get_value` +and `git_config_get_value_multi`. They both read values from an internal +cache generated previously from reading the config files. + +`int git_config_get_value(const char *key, const char **value)`:: + + Finds the highest-priority value for the configuration variable `key`, + stores the pointer to it in `value` and returns 0. When the + configuration variable `key` is not found, returns 1 without touching + `value`. The caller should not free or modify `value`, as it is owned + by the cache. + +`const struct string_list *git_config_get_value_multi(const char *key)`:: + + Finds and returns the value list, sorted in order of increasing priority + for the configuration variable `key`. When the configuration variable + `key` is not found, returns NULL. The caller should not free or modify + the returned pointer, as it is owned by the cache. + +`void git_config_clear(void)`:: + + Resets and invalidates the config cache. + +The config API also provides type specific API functions which do conversion +as well as retrieval for the queried variable, including: + +`int git_config_get_int(const char *key, int *dest)`:: + + Finds and parses the value to an integer for the configuration variable + `key`. Dies on error; otherwise, stores the value of the parsed integer in + `dest` and returns 0. When the configuration variable `key` is not found, + returns 1 without touching `dest`. + +`int git_config_get_ulong(const char *key, unsigned long *dest)`:: + + Similar to `git_config_get_int` but for unsigned longs. + +`int git_config_get_bool(const char *key, int *dest)`:: + + Finds and parses the value into a boolean value, for the configuration + variable `key` respecting keywords like true and false. Integer + values are converted into true/false values (when they are non-zero or + zero, respectively). Other values cause a die(). If parsing is successful, + stores the value of the parsed result in `dest` and returns 0. When the + configuration variable `key` is not found, returns 1 without touching + `dest`. + +`int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest)`:: + + Similar to `git_config_get_bool`, except that integers are copied as-is, + and `is_bool` flag is unset. + +`int git_config_get_maybe_bool(const char *key, int *dest)`:: + + Similar to `git_config_get_bool`, except that it returns -1 on error +
[PATCH v12 2/2] test-config: add tests for the config_set API
Expose the `config_set` C API as a set of simple commands in order to
facilitate testing. Add tests for the `config_set` API as well as for
`git_config_get_*()` family for the usual config files.
Signed-off-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
.gitignore| 1 +
Makefile | 1 +
t/t1308-config-set.sh | 200 ++
test-config.c | 142 +++
4 files changed, 344 insertions(+)
create mode 100755 t/t1308-config-set.sh
create mode 100644 test-config.c
diff --git a/.gitignore b/.gitignore
index 81e12c0..5bfb234 100644
--- a/.gitignore
+++ b/.gitignore
@@ -178,6 +178,7 @@
/gitweb/static/gitweb.min.*
/test-chmtime
/test-ctype
+/test-config
/test-date
/test-delta
/test-dump-cache-tree
diff --git a/Makefile b/Makefile
index 2320de5..b7462e3 100644
--- a/Makefile
+++ b/Makefile
@@ -551,6 +551,7 @@ PROGRAMS += $(patsubst %.o,git-%$X,$(PROGRAM_OBJS))
TEST_PROGRAMS_NEED_X += test-chmtime
TEST_PROGRAMS_NEED_X += test-ctype
+TEST_PROGRAMS_NEED_X += test-config
TEST_PROGRAMS_NEED_X += test-date
TEST_PROGRAMS_NEED_X += test-delta
TEST_PROGRAMS_NEED_X += test-dump-cache-tree
diff --git a/t/t1308-config-set.sh b/t/t1308-config-set.sh
new file mode 100755
index 000..7fdf840
--- /dev/null
+++ b/t/t1308-config-set.sh
@@ -0,0 +1,200 @@
+#!/bin/sh
+
+test_description='Test git config-set API in different settings'
+
+. ./test-lib.sh
+
+# 'check_config get_* section.key value' verifies that the entry for
+# section.key is 'value'
+check_config () {
+ if test $1 = expect_code
+ then
+ expect_code=$2 shift shift
+ else
+ expect_code=0
+ fi
+ op=$1 key=$2 shift shift
+ if test $# != 0
+ then
+ printf %s\n $@
+ fi expect
+ test_expect_code $expect_code test-config $op $key actual
+ test_cmp expect actual
+}
+
+test_expect_success 'setup default config' '
+ cat .git/config \EOF
+ [case]
+ penguin = very blue
+ Movie = BadPhysics
+ UPPERCASE = true
+ MixedCase = true
+ my =
+ foo
+ baz = sam
+ [Cores]
+ WhatEver = Second
+ baz = bar
+ [cores]
+ baz = bat
+ [CORES]
+ baz = ball
+ [my Foo bAr]
+ hi = mixed-case
+ [my FOO BAR]
+ hi = upper-case
+ [my foo bar]
+ hi = lower-case
+ [case]
+ baz = bat
+ baz = hask
+ [lamb]
+ chop = 65
+ head = none
+ [goat]
+ legs = 4
+ head = true
+ skin = false
+ nose = 1
+ horns
+ EOF
+'
+
+test_expect_success 'get value for a simple key' '
+ check_config get_value case.penguin very blue
+'
+
+test_expect_success 'get value for a key with value as an empty string' '
+ check_config get_value case.my
+'
+
+test_expect_success 'get value for a key with value as NULL' '
+ check_config get_value case.foo (NULL)
+'
+
+test_expect_success 'upper case key' '
+ check_config get_value case.UPPERCASE true
+ check_config get_value case.uppercase true
+'
+
+test_expect_success 'mixed case key' '
+ check_config get_value case.MixedCase true
+ check_config get_value case.MIXEDCASE true
+ check_config get_value case.mixedcase true
+'
+
+test_expect_success 'key and value with mixed case' '
+ check_config get_value case.Movie BadPhysics
+'
+
+test_expect_success 'key with case sensitive subsection' '
+ check_config get_value my.Foo bAr.hi mixed-case
+ check_config get_value my.FOO BAR.hi upper-case
+ check_config get_value my.foo bar.hi lower-case
+'
+
+test_expect_success 'key with case insensitive section header' '
+ check_config get_value cores.baz ball
+ check_config get_value Cores.baz ball
+ check_config get_value CORES.baz ball
+ check_config get_value coreS.baz ball
+'
+
+test_expect_success 'key with case insensitive section header variable' '
+ check_config get_value CORES.BAZ ball
+ check_config get_value cores.baz ball
+ check_config get_value cores.BaZ ball
+ check_config get_value cOreS.bAz ball
+'
+
+test_expect_success 'find value with misspelled key' '
+ check_config expect_code 1 get_value my.fOo Bar.hi Value not found
for \my.fOo Bar.hi\
+'
+
+test_expect_success 'find value with the highest priority' '
+ check_config get_value case.baz hask
+'
+
+test_expect_success 'find integer value for a key' '
+ check_config get_int lamb.chop 65
+'
+
+test_expect_success 'find integer if value is non parse-able' '
+ check_config expect_code 128 get_int lamb.head
+'
+
+test_expect_success
Re: [PATCH 0/7] Rewrite `git_config()` using config-set API
Tanay Abhra tanay...@gmail.com writes: I am attaching the v12 with two new functions git_configset_get_string() git_configset_get_string_const(). Didn't you intend to change git_config_get_string to let it die in case of error instead of returning an error code? -- 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 0/7] Rewrite `git_config()` using config-set API
On 7/24/2014 9:09 PM, Matthieu Moy wrote: Tanay Abhra tanay...@gmail.com writes: I am attaching the v12 with two new functions git_configset_get_string() git_configset_get_string_const(). Didn't you intend to change git_config_get_string to let it die in case of error instead of returning an error code? Yup, but it is the part of the new series not the old one. I sent this revised patch just for solving the constness debate. Also, I would need git_die_config() to print a proper error message which comes in the 7 part series not this one. -- 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 0/7] Rewrite `git_config()` using config-set API
Tanay Abhra tanay...@gmail.com writes: On 7/24/2014 9:09 PM, Matthieu Moy wrote: Tanay Abhra tanay...@gmail.com writes: I am attaching the v12 with two new functions git_configset_get_string() git_configset_get_string_const(). Didn't you intend to change git_config_get_string to let it die in case of error instead of returning an error code? Yup, but it is the part of the new series not the old one. I sent this revised patch just for solving the constness debate. Also, I would need git_die_config() to print a proper error message which comes in the 7 part series not this one. Ah, right, you don't have line numbers yet, so you can't die properly. So, hopefully, this part can be considered done, and we can continue building on top. As a side effect, I guess Junio will apply this on top of master so the string interning API will be available immediately at the tip of the branch. -- 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
[PATCH] git-svn: Avoid systematic prompt for client certificate when using git svn branch
When a client certificate is required to connect to a Subversion repository,
the certificate location and password may be stored in Subversion config
directory.
Commands like git svn init/fetch/dcommit do not prompt for client
certificate/password
if the location is set in SVN config file, but git svn branch does not use
the config
directory, resulting in prompting for certificate location/password all the
time.
Build instance of SVN::Client in branch_cmd() with SVN config directory option
instead
of authentication baton. SVN::Client then builds its own authentication baton
using information from the config directory.
Signed-off-by: Monard Vong travelingsou...@gmail.com
---
git-svn.perl | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/git-svn.perl b/git-svn.perl
index 0a32372..1f41ee1 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1161,7 +1161,9 @@ sub cmd_branch {
::_req_svn();
my $ctx = SVN::Client-new(
- auth= Git::SVN::Ra::_auth_providers(),
+ config = SVN::Core::config_get_config(
+ $Git::SVN::Ra::config_dir
+ ),
log_msg = sub {
${ $_[0] } = defined $_message
? $_message
--
1.9.3
--
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 3/5] checkout --to: no auto-detach if the ref is already checked out
Duy Nguyen pclo...@gmail.com writes: On Thu, Jul 24, 2014 at 4:16 AM, Junio C Hamano gits...@pobox.com wrote: + if (strbuf_read_file(sb, path.buf, 0) = 0 || + !skip_prefix(sb.buf, ref:, start)) + goto done; while (isspace(*start)) start++; end = start; while (*end !isspace(*end)) end++; Not new in this round of update, and may not even be an issue, but: - Earlier, the code returned early on a negative return value from read-file (i.e., an error), but this round it also does so for zero. Intended? Yes. But it does not make any difference. strbuf_read_file returns sb.len, if it's empty, the next skip_prefix would fail anyway. Yes but changing 0 to = 0 is inconsistent with that; I would understand if you changed it to = 4, which would be consistent with the reasoning, though. The code in the patch, which is something in between, does not make much sense to me. I think more about echo abc $this_file where the echo command may output '\r\n' on Windows (wild guess though, I don't use Windows much). I think I'm going with _rtrim. To expect 'echo' into the file is to expect and encourage that people muck with the internal implementation details by hand, which we do not generally do for things inside .git [*1*]. If we consider the contents of $this_file not an implementation detail but a part of the published API (i.e. writing this string into the file is a valid way to make Git do this), rtrim would at least be consistent with how the existing code deals with symrefs, so I wouldn't say does not make much sense if you are going in that direction ;-) [Footnote] *1* ... except for .git/config, to which we say It's a simple text file; don't be afraied to edit it away!. -- 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 3/7] add a test for semantic errors in config files
Matthieu Moy matthieu@grenoble-inp.fr writes: Tanay Abhra tanay...@gmail.com writes: + test_when_finished mv .git/config.old .git/config + echo [alias]\n br .git/config Is the use of \n portable? Yes, you are right, will replace with printf in the next patch. ... or a cat .git/config \EOF, since this is the construct used elsewhere in the script. That sounds much better ;-) 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 5/7] enforce `xfuncname` precedence over `funcname`
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: in my ~/.gitconfig and then for a particular project I wanted to use a custom pattern in its .git/config but it was sufficient to define the pattern without using extended regexp, I would be tempted to say diff.foo.funcname Wine$ The point is: to do that, you need to know that funcname exists, hence read archives of the doc before 2008 (it disapeared in 45d9414fa5599b41578625961b53e18a9b9148c7) or read the code. And if I read correctly the commit message for the commit, funcname is not portable so you should use xfuncname anyway. The real reason for this change is to let the code work with the new git_config, but I think it's reasonable not to bother with the original behavior for a feature deprecated so long ago. We may be able to explain funcname vs xfuncname away, but the problem is much deeper, and it is not just you and Tanay, but anybody who thought that it is a natural and logical conclusion to emulate git_config() by iterating over in-core hashtable X- We have assumed that it is OK for git_config() to call its callbacks with any random order of keys as long as the values for the same key are given in the same order as the original read from file every time implementation would have called. The assumption overlooked the possibility that values given to two different keys can semantically interact. $foo.funcname and $foo.xfuncname being two different ways to define the same piece of information is merely one of the many ways such interactions can happen. For example, by assuming that orders of callbacks across keys does not matter, we would be breaking scripts that expected to be able to deal with something like this: [character] name = Snoopy color = white black name = Hobbes color = yellow white black For *our* own data, we can force them to be spelled this way instead: [character Snoopy] color = white black [character Hobbes] color = yellow white black but that misses the point, as our config file format and its semantics are not only about .git/config but the system is designed and promoted to be a way for third-party applications to store their own data as well. Because we do not condone using libgit.a as a library to link into third-party applications, git_config() at the C level may not have to read a random third-party data and call its callback in the predictable way, but this shows us that git config -l interface must return the data in the same order as we have done always by either using the _raw interface to return things uncached, or teaching by git_config() to also be predicatable. That said, I think the commit message should be improved (recall the drawbacks of funcname). In any case, I agree that the log message and the subject is wrong. It is not that we want to give xfuncname precedence over funcname; such a behaviour is undesirable if both were in wide use. It is papering over the fallout that comes from the loss of ordering information, which is imposed by the data structure chosen to represent a config_set. I haven't formed a firm opinion whether preserving the order is necessary at git_config() iteration level yet. If the only in-core user that will be broken by not doing so is xfuncname vs funcname, it may not be too bad, but it will constrain us in the future, which is a lot bigger problem. We will be forbidden from correcting a UI mistake by using the approach we took to transtion funcname over to xfuncname (i.e. giving users funcname and allowing the platform BRE parser that may or may not allow the users to write backslashed ERE is spreading possible incompatibility among the participants of a project; explicitly stating that the value is ERE has fewer compatibility issues), while still supporting funcname and have them interact in a sane 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: `ab | (cd cd git apply -)' fails with v2.0.0
Michael J Gruber g...@drmicha.warpmail.net writes: Steffen Nurpmeso venit, vidit, dixit 24.07.2014 15:29: Hello (again, psst, after a long time), it happened yesterday that i needed to do $ git diff HEAD:FILE COMMIT:SAME-FILE | (cd src git apply -) ... Ah little more context would help. Are you diffing files in the subdir src, or a file at the root which happens to be present in the subdir src as well? As the treeish:path form is not meant to produce git apply applicable patch in the first place, I am not sure what the OP is trying to achieve in the first place. Not just how many leading levels to strip? but which file is being modified? does not appear in a usable form. For example, here is what you would see: $ git diff HEAD:GIT-VERSION-GEN maint:GIT-VERSION-GEN diff --git a/HEAD:GIT-VERSION-GEN b/maint:GIT-VERSION-GEN index 40adbf7..0d1a86c 100755 --- a/HEAD:GIT-VERSION-GEN +++ b/maint:GIT-VERSION-GEN @@ -1,7 +1,7 @@ ... and neither HEAD:GIT-VERSION-GEN nor maint:GIT-VERSION-GEN is the file being modified (GIT-VERSION-GEN is). I would understand if the upstream of the pipe were $ git diff HEAD maint -- GIT-VERSION-GEN | ... though. Needless to say, if the place cd goes is not a worktree controlled by git, then git apply would not know where the top-level of the target tree is, so even though the input with the corrected command on the upstream side of the pipe tells it which file is being modified, it needs to be told with the proper -pn parameter how many leading levels to strip. -- 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
[ANNOUNCE] Git v2.0.3
The latest maintenance release Git v2.0.3 is now available at the usual places. Hopefully it would be the final maintenance release for the v2.0 series. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.0.3' tag and the 'maint' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v2.0.3 Release Notes * An ancient rewrite passed a wrong pointer to a curl library function in a rarely used code path. * filter-branch left an empty single-parent commit that results when all parents of a merge commit gets mapped to the same commit, even under --prune-empty. * log --show-signature incorrectly decided the color to paint a mergetag that was and was not correctly validated. * log --show-signature did not pay attention to --graph option. Also a lot of fixes to the tests and some updates to the docs are included. Changes since v2.0.2 are as follows: Abbaad Haider (1): http-push.c: make CURLOPT_IOCTLDATA a usable pointer Ben Walton (1): compat/bswap.h: fix endianness detection Brian Gesiak (12): builtin/ls-remote.c: rearrange xcalloc arguments builtin/remote.c: rearrange xcalloc arguments commit.c: rearrange xcalloc arguments config.c: rearrange xcalloc arguments diff.c: rearrange xcalloc arguments http-push.c: rearrange xcalloc arguments imap-send.c: rearrange xcalloc arguments notes.c: rearrange xcalloc arguments pack-revindex.c: rearrange xcalloc arguments reflog-walk.c: rearrange xcalloc arguments remote.c: rearrange xcalloc arguments transport-helper.c: rearrange xcalloc arguments Charles Bailey (2): compat/bswap.h: detect endianness on more platforms that don't use BYTE_ORDER filter-branch: eliminate duplicate mapped parents Elia Pinto (1): scripts: export VAR=VALUE construct is not portable Jeremiah Mahler (3): Documentation: wording fixes in the user manual and glossary t/t7810-grep.sh: remove duplicate test_config() api-strbuf.txt minor typos Johannes Sixt (1): fix brown paper bag breakage in t5150-request-pull.sh Jonathan McCrohan (1): git-instaweb: add support for Apache 2.4 Junio C Hamano (3): compat/bswap.h: restore preference __BIG_ENDIAN over BIG_ENDIAN scripts: more export VAR=VALUE fixes Git 2.0.3 Michael J Gruber (1): log: correctly identify mergetag signature verification status Philip Oakley (1): doc: give some guidelines for error messages René Scharfe (2): use xcalloc() to allocate zero-initialized memory use xmemdupz() to allocate copies of strings given by start and length Stefan Beller (2): git.1: switch homepage for stats .mailmap: combine Stefan Beller's emails Stepan Kasal (1): t5000, t5003: do not use test_cmp to compare binary files Yi EungJun (1): http-protocol.txt: Basic Auth is defined in RFC 2617, not RFC 2616 Zoltan Klinger (1): log: fix indentation for --graph --show-signature brian m. carlson (1): Documentation: fix missing text for rev-parse --verify -- 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 3/5] checkout --to: no auto-detach if the ref is already checked out
Junio C Hamano gits...@pobox.com writes: Duy Nguyen pclo...@gmail.com writes: On Thu, Jul 24, 2014 at 4:16 AM, Junio C Hamano gits...@pobox.com wrote: + if (strbuf_read_file(sb, path.buf, 0) = 0 || + !skip_prefix(sb.buf, ref:, start)) + goto done; while (isspace(*start)) start++; end = start; while (*end !isspace(*end)) end++; Not new in this round of update, and may not even be an issue, but: - Earlier, the code returned early on a negative return value from read-file (i.e., an error), but this round it also does so for zero. Intended? Yes. But it does not make any difference. strbuf_read_file returns sb.len, if it's empty, the next skip_prefix would fail anyway. Yes but changing 0 to = 0 is inconsistent with that; I would understand if you changed it to = 4, which would be consistent with the reasoning, though. Just to make sure. I am not saying changing 0 to = 4 is a good idea. I think checking for strbuf_read_file() failure with 0 and then checking for malformatted input (or detached head perhaps?) with !skip_prefix(), i.e. testing two logically separate things with two separate conditions concatenated together with ||, would be the most natural way to express it. -- 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/7] config.c: fix accuracy of line number in errors
Tanay Abhra tanay...@gmail.com writes: On 7/24/2014 3:19 AM, Junio C Hamano wrote: Tanay Abhra tanay...@gmail.com writes: If a callback returns a negative value to `git_config*()` family, they call `die()` while printing the line number and the file name. Currently the printed line number is off by one, thus printing the wrong line number. Make `linenr` point to the line we just parsed during the call to callback to get accurate line number in error messages. Discovered-by: Tanay Abhra tanay...@gmail.com Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr Thanks. I am not sure what to read in these two lines. Was the fix done by you or Matthieu? I misunderstood the meaning of the message trailers. I will correct it in the next re roll. Well, that does not really answer my question, and it does not tell us if you now understand the meaning of trailers correctly, or replaced an earlier misunderstanding with a different misunderstanding ;-) More importantly, it would not help me interpret what you mean when you write a sequence like this: From: tanay S-o-b: matthieu S-o-b: tanay which does not quite make sense and leave the reader puzzled. If the patch was authored by you and helped by matthieu, the first S-o-b would be lying. If the patch was written by matthieu and you are merely relaying, then the authorship From is lying. If the patch was written by you and matthieu is relaying, then the two S-o-bs are in incorrect order. -- 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 5/7] enforce `xfuncname` precedence over `funcname`
I haven't formed a firm opinion whether preserving the order is necessary at git_config() iteration level yet. If the only in-core user that will be broken by not doing so is xfuncname vs funcname, it may not be too bad, but it will constrain us in the future, which is a lot bigger problem. If we give users a choice between two methods git_config_raw() git_config_cache(), it would give us a easy fallback if we want to do something like support xfuncname and funcname for performing the same function differently. For core the only test failing was xfuncname vs funcname, so the situation is not as bad as you think. One course of action would be leave git_config() as it is, so that third party apps may not be broken. Provide a function like git_config_cache(), then rename all the git_config() calls in core to git_config_cache(), fallback to git_config() where it is not applicable (for example, git config -l). I haven't thought a lot about it and I haven't heard Matthieu's opinion about it yet. Also can you name any third party apps that use the git_config() system on which I can test the patches. I have seen gitk and gitgui using the config files to save data. Cheers, Tanay Abhra. We will be forbidden from correcting a UI mistake by using the approach we took to transtion funcname over to xfuncname (i.e. giving users funcname and allowing the platform BRE parser that may or may not allow the users to write backslashed ERE is spreading possible incompatibility among the participants of a project; explicitly stating that the value is ERE has fewer compatibility issues), while still supporting funcname and have them interact in a sane 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 1/7] config.c: fix accuracy of line number in errors
On 7/25/2014 12:01 AM, Junio C Hamano wrote: Tanay Abhra tanay...@gmail.com writes: On 7/24/2014 3:19 AM, Junio C Hamano wrote: Tanay Abhra tanay...@gmail.com writes: If a callback returns a negative value to `git_config*()` family, they call `die()` while printing the line number and the file name. Currently the printed line number is off by one, thus printing the wrong line number. Make `linenr` point to the line we just parsed during the call to callback to get accurate line number in error messages. Discovered-by: Tanay Abhra tanay...@gmail.com Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr This patch should have looked like, From: Matthieu Moy matthieu@grenoble-inp.fr commit message Commit-message-by: Tanay Abhra tanay...@gmail.com Thanks. I am not sure what to read in these two lines. Was the fix done by you or Matthieu? I misunderstood the meaning of the message trailers. I will correct it in the next re roll. Well, that does not really answer my question, and it does not tell us if you now understand the meaning of trailers correctly, or replaced an earlier misunderstanding with a different misunderstanding ;-) More importantly, it would not help me interpret what you mean when you write a sequence like this: From: tanay S-o-b: matthieu S-o-b: tanay Actually it was because that patch contained fixup patch from Matthieu squashed into it, that is why there were two signoffs. which does not quite make sense and leave the reader puzzled. If the patch was authored by you and helped by matthieu, the first S-o-b would be lying. If the patch was written by matthieu and you are merely relaying, then the authorship From is lying. If the patch was written by you and matthieu is relaying, then the two S-o-bs are in incorrect order. -- 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 v12 1/2] add `config_set` API for caching config-like files
Tanay Abhra tanay...@gmail.com writes:
+int git_configset_get_string_const(struct config_set *cs, const char *key,
const char **dest)
+{
+ const char *value;
+ if (!git_configset_get_value(cs, key, value))
+ return git_config_string(dest, key, value);
+ else
+ return 1;
+}
+
+int git_configset_get_string(struct config_set *cs, const char *key, char
**dest)
+{
+ const char *value;
+ if (!git_configset_get_value(cs, key, value)) {
+ if (!value)
+ return config_error_nonbool(key);
+ *dest = xstrdup(value);
+ return 0;
+ }
+ else
+ return 1;
+}
Hmm, do we really need duplicate and an almost identical
implementations?
I would have expected either one of these two (expecting the latter
more than the former from the discussion):
1. Because git_configset_get_string_const() returns a const string
not to be touched by the caller, it does not even xstrdup(),
while git_configset_get_string() does.
2. These behave identically, and the only reason we have two is
because some callers want to receive the string in char *
while others want to use const char *.
If you were going route #1, then you would need duplicate but subtly
different implementations; get_string_const() variant would not be
calling git_config_string() because it does xstrdup() the value and
give the caller a new string the caller has to free.
If you were going route #2, the I would have expected there is only
one implementation, _get_string(), and _get_string_const() would
call it while casting the dest parameter it receives.
--
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 p4 test: fix failure in 9814-git-p4-rename.sh Was: Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?
Am 23.07.2014 23:28, schrieb Christoph Bonitz:
The scenario in the rename test makes unnecessary assumptions about
which file git file-tree will detect as a source for a copy-operations.
Furthermore, copy detection is not tested by checking the resulting
perforce revision history via p4 filelog, but via git diff-tree.
This patch makes the test more robust by accepting each of the possible
sources, and more rigorous by doing so via p4 filelog.
---
Please sign off your patch.
t/t9814-git-p4-rename.sh | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh
index 1fc1f5f..4068510 100755
--- a/t/t9814-git-p4-rename.sh
+++ b/t/t9814-git-p4-rename.sh
@@ -156,18 +156,16 @@ test_expect_success 'detect copies' '
git diff-tree -r -C HEAD
git p4 submit
p4 filelog //depot/file10
- p4 filelog //depot/file10 | grep -q branch from //depot/file
+ p4 filelog //depot/file10 | grep -q branch from //depot/file2
cp file2 file11
git add file11
git commit -a -m Copy file2 to file11
git diff-tree -r -C --find-copies-harder HEAD
- src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2)
- test $src = file10
git config git-p4.detectCopiesHarder true
git p4 submit
p4 filelog //depot/file11
- p4 filelog //depot/file11 | grep -q branch from //depot/file
+ p4 filelog //depot/file11 | grep -q -E branch from //depot/file(2|10)
cp file2 file12
echo some text file12
@@ -177,7 +175,7 @@ test_expect_success 'detect copies' '
level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 |
cut -d -f5 | sed s/C0*//)
test -n $level test $level -gt 0 test $level -lt 98
src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2)
- test $src = file10 || test $src = file11
+ test $src = file2 || test $src = file10 || test $src = file11
You can't test for alternatives in this way. It's already wrong in the
original line, which is from 795fcb0e (avoid test cond -a/-o cond),
and breaks the chain. You need braces like this:
{ test $src = file2 || test $src = file10 || test $src = file11; }
or you wrap it up in a case statement.
git config git-p4.detectCopies $(($level + 2))
git p4 submit
p4 filelog //depot/file12
@@ -190,12 +188,10 @@ test_expect_success 'detect copies' '
git diff-tree -r -C --find-copies-harder HEAD
level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 |
cut -d -f5 | sed s/C0*//)
test -n $level test $level -gt 2 test $level -lt 100
- src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2)
- test $src = file10 || test $src = file11 || test $src = file12
git config git-p4.detectCopies $(($level - 2))
git p4 submit
p4 filelog //depot/file13
- p4 filelog //depot/file13 | grep -q branch from //depot/file
+ p4 filelog //depot/file13 | grep -q -E branch from
//depot/file(2|10|11|12)
)
'
I see a few other no-nos in the context of the changes, in particular,
pipelines where git is not the last command; these would not catch
failures in the git commands. But a fix for that is certainly outside
the scope of this patch.
-- 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 5/7] enforce `xfuncname` precedence over `funcname`
Tanay Abhra tanay...@gmail.com writes: For core the only test failing was xfuncname vs funcname, Being a little pessimistic: there may be other cases where the hashtable magically gives the right order for existing tests, but that would fail for untested use-cases. But I can't think of any such case. so the situation is not as bad as you think. One course of action would be leave git_config() as it is, so that third party apps may not be broken. Provide a function like git_config_cache(), then rename all the git_config() calls in core to git_config_cache(), fallback to git_config() where it is not applicable (for example, git config -l). I think Junio's point about git config -l is correct: we should just keep git_config_raw there. OTOH, renaming git_config to git_config_cache seems a lot of code churn, so I'd keep the name git_config. Perhaps git_config_raw is no longer a good name and it could be called git_config_ordered. If we keep one call to git_config_raw there, then maybe we can use it for xfuncname/funcname too, and keep the behavior unchanged. Also can you name any third party apps that use the git_config() system on which I can test the patches. There are probably tons of. I can think of git-multimail. -- 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 1/7] config.c: fix accuracy of line number in errors
Tanay Abhra tanay...@gmail.com writes: On 7/25/2014 12:01 AM, Junio C Hamano wrote: Tanay Abhra tanay...@gmail.com writes: On 7/24/2014 3:19 AM, Junio C Hamano wrote: Tanay Abhra tanay...@gmail.com writes: If a callback returns a negative value to `git_config*()` family, they call `die()` while printing the line number and the file name. Currently the printed line number is off by one, thus printing the wrong line number. Make `linenr` point to the line we just parsed during the call to callback to get accurate line number in error messages. Discovered-by: Tanay Abhra tanay...@gmail.com Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr This patch should have looked like, From: Matthieu Moy matthieu@grenoble-inp.fr commit message Commit-message-by: Tanay Abhra tanay...@gmail.com Yes, the code itself was mine, and Tanay wrote the commit message. -- 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 5/7] enforce `xfuncname` precedence over `funcname`
On Thu, Jul 24, 2014 at 08:47:45PM +0200, Matthieu Moy wrote: Tanay Abhra tanay...@gmail.com writes: Also can you name any third party apps that use the git_config() system on which I can test the patches. There are probably tons of. I can think of git-multimail. CGit [1] is probably the only one that links with libgit.a and uses the internal C API. [1] http://git.zx2c4.com/cgit/ -- 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 5/7] enforce `xfuncname` precedence over `funcname`
Matthieu Moy matthieu@grenoble-inp.fr writes: Tanay Abhra tanay...@gmail.com writes: For core the only test failing was xfuncname vs funcname, Being a little pessimistic: there may be other cases where the hashtable magically gives the right order for existing tests, but that would fail for untested use-cases. But I can't think of any such case. so the situation is not as bad as you think. One course of action would be leave git_config() as it is, so that third party apps may not be broken. Provide a function like git_config_cache(), then rename all the git_config() calls in core to git_config_cache(), fallback to git_config() where it is not applicable (for example, git config -l). I think Junio's point about git config -l is correct: we should just keep git_config_raw there. I have a slight preference of making git_config() do the right thing and take advantage of caching behaviour, to be honest. How much extra effort is necessary in your code to carry a piece of information, in addition to what lets you say here are the values associated with that key in the order we read from the files, in order to be able to say by the way, here is the order of key-value pairs, if you want to show everything we read in the same order? If it would be excessive, using _raw() could be an easy way to punt, but because we know it is easy to decide to punt, I'd like to see us see if a real solution is feasible first before punting. Also can you name any third party apps that use the git_config() system on which I can test the patches. There are probably tons of. I can think of git-multimail. This question does not really matter. Among the various points, I actually think the last one you omitted from your quote, closing door to one useful way to fix UI mistakes in the future, is the most serious one. -- 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 5/7] enforce `xfuncname` precedence over `funcname`
On 7/25/2014 12:50 AM, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Tanay Abhra tanay...@gmail.com writes: For core the only test failing was xfuncname vs funcname, Being a little pessimistic: there may be other cases where the hashtable magically gives the right order for existing tests, but that would fail for untested use-cases. But I can't think of any such case. so the situation is not as bad as you think. One course of action would be leave git_config() as it is, so that third party apps may not be broken. Provide a function like git_config_cache(), then rename all the git_config() calls in core to git_config_cache(), fallback to git_config() where it is not applicable (for example, git config -l). I think Junio's point about git config -l is correct: we should just keep git_config_raw there. I have a slight preference of making git_config() do the right thing and take advantage of caching behaviour, to be honest. How much extra effort is necessary in your code to carry a piece of information, in addition to what lets you say here are the values associated with that key in the order we read from the files, in order to be able to say by the way, here is the order of key-value pairs, if you want to show everything we read in the same order? If it would be excessive, using _raw() could be an easy way to punt, but because we know it is easy to decide to punt, I'd like to see us see if a real solution is feasible first before punting. I am thinking over it, lets see if there is a way before we take the easy route. Also can you name any third party apps that use the git_config() system on which I can test the patches. There are probably tons of. I can think of git-multimail. This question does not really matter. Among the various points, I actually think the last one you omitted from your quote, closing door to one useful way to fix UI mistakes in the future, is the most serious one. If we take the easy way out, fixing UI mistakes would be easier, just replace git_config_cache() with git_config_raw() for such cases. -- 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 5/7] enforce `xfuncname` precedence over `funcname`
Tanay Abhra tanay...@gmail.com writes: If we take the easy way out, fixing UI mistakes would be easier, just replace git_config_cache() with git_config_raw() for such cases. I do not think that would fly well. The kind of let's migrate funcname users to xfuncname while still supporting the old uses change will be done in the callback functions like userdiff_config(). But it is very typical that multiple config callback functions are cascaded (e.g. many eventually end up calling git_default_core_config()); in order to a workaround you suggest to help a callback in deep in a cascade chain would require you to see which ones among all the callback functions will eventually call the callback you are updating for migration and update all git_config() calls to git_config_raw(). If you fix it properly (assuming it is feasible; I haven't heard if you even tried to see how much work it would involve), you do not need to introduce git_config_cached() (or _raw() for that matter), which is a huge plus. git_config() would instead do the right thing automatically, giving the same semantics except that it does not read the same file twice when it is known that the file has not changed. I can understand If we take the easy way out, we do not have to do much. But it would not make it any easier---it essentially closes the door for oops, funcname is error-prone; let's give people xfuncname type of migration. -- 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 0/7] Rewrite `git_config()` using config-set API
Matthieu Moy matthieu@grenoble-inp.fr writes: As a side effect, I guess Junio will apply this on top of master so the string interning API will be available immediately at the tip of the branch. Thanks for a heads-up. The two-patch series does not use the interning, but does use string_list_init(), which is recent, and I will have to apply on a newer base than I have been applying its earlier iterations. -- 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 0/5] coverity mixed bag
Jeff King p...@peff.net writes: Since Stefan has recently started feeding git builds to coverity, I spent a few minutes poking through the results. There are tons of false positives, so there is some work to be done there with tweaking our coverity models. But there are some real issues, too. Here are fixes for the handful that I looked at. [1/5]: receive-pack: don't copy dir parameter [2/5]: free ref string returned by dwim_ref [3/5]: transport: fix leaks in refs_from_alternate_cb [4/5]: fix memory leak parsing core.commentchar [5/5]: apply: avoid possible bogus pointer -Peff Thanks, they all make sense to me. I'd probably have to wiggle 4/5 a bit to port the fix over to both maint and master, though. -- 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 5/7] enforce `xfuncname` precedence over `funcname`
On 24/07/14 20:54, Junio C Hamano wrote: Tanay Abhra tanay...@gmail.com writes: If we take the easy way out, fixing UI mistakes would be easier, just replace git_config_cache() with git_config_raw() for such cases. I do not think that would fly well. The kind of let's migrate funcname users to xfuncname while still supporting the old uses change will be done in the callback functions like userdiff_config(). But it is very typical that multiple config callback functions are cascaded (e.g. many eventually end up calling git_default_core_config()); in order to a workaround you suggest to help a callback in deep in a cascade chain would require you to see which ones among all the callback functions will eventually call the callback you are updating for migration and update all git_config() calls to git_config_raw(). If you fix it properly (assuming it is feasible; I haven't heard if you even tried to see how much work it would involve), you do not need to introduce git_config_cached() (or _raw() for that matter), which is a huge plus. git_config() would instead do the right thing automatically, giving the same semantics except that it does not read the same file twice when it is known that the file has not changed. I haven't been following this conversation too closely, so if I have grasped the wrong end of this stick, please accept my apologies! ;-) Usually if you need to iterate the values in a hash-table in the order of key insertion, you would simply link the hash-table entries into a linked list. This assumes that the keys are distinct, or if not, that you are using a 'multi-map' type of hash-table. Here, if memory serves me, you are doing the 'multi' bit yourself within the single hash-table entry for a given key; so its not quite so easy. However, I think it you could create a list of pointer to hash-table entry, string-list index pairs in the config_set and use that to do the iteration. A bit ugly, but it should work. HTH 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 3/5] checkout --to: no auto-detach if the ref is already checked out
Duy Nguyen pclo...@gmail.com writes: On Wed, Jul 23, 2014 at 8:48 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: Nguyễn Thái Ngọc Duy venit, vidit, dixit 23.07.2014 13:43: + if (advice_checkout_to) + die(_(%s is already checked out at %s.\n + Either use --detach or -b together with --to + or switch branch in the the other checkout.), or switch to a different branch in the other checkout. But maybe we can be even more helpful, like: %s is already checked out at %s.\n Either checkout the detached head of branch %s using\n git checkout --detach --to %s %s\n or checkout a new branch based off %s using\n git checkout --to %s -b %s newbranch %s\n or switch to a different branch in the other checkout. if we can figure out the appropriate arguments at this point in the code. We would not be able to construct the exact command that the user has entered, so perhaps git checkout --detach more options %s git checkout -b new branch more options %s ? Note that this does not only occur when --to is given. If you have two checkouts associated to the same repo, git checkout foo on one checkout when foo is held by another checkout would cause the same error. I'll need to think of a better name than advice.checkoutTo. I am not sure if we need to say anything more than the first line of the message you have in your patch. To fork a new branch at the commit the user is interested in to check it out, or not bothering with the branch and detach, are both very normal parts of user's Git toolchest, nothing particularly special. As long as the most important point, i.e. in the new world order, unlike the contrib/workdir hack, you cannot check out the same branch at two different places, is clearly conveyed and understood, everything else should follow naturally, no? -- 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 p4 test: fix failure in 9814-git-p4-rename.sh Was: Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?
Johannes Sixt j...@kdbg.org writes:
@@ -177,7 +175,7 @@ test_expect_success 'detect copies' '
level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 |
cut -d -f5 | sed s/C0*//)
test -n $level test $level -gt 0 test $level -lt 98
src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2)
- test $src = file10 || test $src = file11
+ test $src = file2 || test $src = file10 || test $src = file11
You can't test for alternatives in this way. It's already wrong in the
original line, which is from 795fcb0e (avoid test cond -a/-o cond),
and breaks the chain. You need braces like this:
{ test $src = file2 || test $src = file10 || test $src = file11; }
or you wrap it up in a case statement.
...
)
'
I see a few other no-nos in the context of the changes, in particular,
pipelines where git is not the last command; these would not catch
failures in the git commands. But a fix for that is certainly outside
the scope of this patch.
Yuck. Thanks for spotting.
Perhaps we should apply a preliminary clean-up before doing anything
else, perhaps? The change in 9814 is a post 2.0 regression.
t/t9814-git-p4-rename.sh | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh
index 1fc1f5f..95f4421 100755
--- a/t/t9814-git-p4-rename.sh
+++ b/t/t9814-git-p4-rename.sh
@@ -177,7 +177,10 @@ test_expect_success 'detect copies' '
level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d
| cut -f1 | cut -d -f5 | sed s/C0*//)
test -n $level test $level -gt 0 test $level -lt 98
src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d |
cut -f2)
- test $src = file10 || test $src = file11
+ case $src in
+ file10 | file11) : ;; # happy
+ *) false ;; # not
+
git config git-p4.detectCopies $(($level + 2))
git p4 submit
p4 filelog //depot/file12
@@ -191,7 +194,10 @@ test_expect_success 'detect copies' '
level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d
| cut -f1 | cut -d -f5 | sed s/C0*//)
test -n $level test $level -gt 2 test $level -lt
100
src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d |
cut -f2)
- test $src = file10 || test $src = file11 || test $src =
file12
+ case $src in
+ file10 | file11 | file12) : ;; # happy
+ *) false ;; # not
+
git config git-p4.detectCopies $(($level - 2))
git p4 submit
p4 filelog //depot/file13
--
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 feature-branch
Hi A small tool I wrote that is useful for some workflows. I thought it'd be worth sharing. https://github.com/sheldon/git-feature-branch/ Sheldon -- 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
What's cooking in git.git (Jul 2014, #05; Thu, 24)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. We would need to start slowing down to prepare for -rc0 preview at the end of this week and then feature freeze. Some topics that joined 'next' late may want to stay there for the remainder of this cycle. Many of the accumulated fixes have been flushed to 'maint' and Git 2.0.3 has been tagged. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * jk/tag-sort (2014-07-17) 2 commits (merged to 'next' on 2014-07-21 at bc34738) + tag: support configuring --sort via .gitconfig + tag: fix --sort tests to use cat-\EOF format Teach git tag to pay attention to tag.sort configuration, to be used as the default sort order when no --sort=value is given. * mb/local-clone-after-applying-insteadof (2014-07-17) 1 commit (merged to 'next' on 2014-07-21 at ebe07c2) + use local cloning if insteadOf makes a local URL Apply the if cloning from a local disk, physically copy repository using hardlinks, unless otherwise told not to with --no-local optimization when url.*.insteadOf mechanism rewrites a git clone $URL that refers to a repository over the network to a clone from a local disk. * rs/fix-unlink-unix-socket (2014-07-21) 1 commit (merged to 'next' on 2014-07-22 at fad8c29) + unix-socket: remove stale socket before calling chdir() The unix-domain socket used by the sample credential cache daemon tried to unlink an existing stale one at a wrong path, if the path to the socket was given as an overlong path that does not fit in sun_path member of the sockaddr_un structure. * ta/string-list-init (2014-07-21) 2 commits (merged to 'next' on 2014-07-21 at 63e8891) + replace memset with string-list initializers + string-list: add string_list initializer helper function (this branch is tangled with ta/config-set.) -- [New Topics] * nd/multiple-work-trees-1 (2014-07-23) 5 commits - environment.c: fix incorrect git_graft_file initialization - checkout --to: fix dangling pointers in remove_junk() - checkout --to: no auto-detach if the ref is already checked out - prune --repos: fix uninitialized access - gitrepository-layout.txt: s/ignored/ignored if/ (this branch uses nd/multiple-work-trees.) Continue polishing nd/multiple-work-trees topic in 'next'. * jk/misc-fixes-maint (2014-07-24) 5 commits - apply: avoid possible bogus pointer - fix memory leak parsing core.commentchar - transport: fix leaks in refs_from_alternate_cb - free ref string returned by dwim_ref - receive-pack: don't copy dir parameter Miscellaneous fixes. Will merge to 'next' and then to 'master'. * rs/ref-transaction-reflog (2014-07-23) 15 commits - refs.c: allow deleting refs with a broken sha1 - refs.c: remove lock_any_ref_for_update - refs.c: make unlock_ref/close_ref/commit_ref static - refs.c: rename log_ref_setup to create_reflog - reflog.c: use a reflog transaction when writing during expire - refs.c: allow multiple reflog updates during a single transaction - refs.c: only write reflog update if msg is non-NULL - refs.c: add a flag to allow reflog updates to truncate the log - refs.c: add a transaction function to append a reflog entry - lockfile.c: make hold_lock_file_for_append preserve meaningful errno - refs.c: add a function to append a reflog entry to a fd - refs.c: add a new update_type field to ref_update - refs.c: rename the transaction functions - refs.c: make ref_transaction_delete a wrapper for ref_transaction_update - refs.c: make ref_transaction_create a wrapper to ref_transaction_update (this branch uses rs/ref-transaction and rs/ref-transaction-1.) Cover updates to reflog with the same transaction mechanism as used for reflog manipulations. -- [Stalled] * jk/tag-contains (2014-06-30) 8 commits . perf: add tests for tag --contains . tag: use commit_contains . commit: provide a fast multi-tip contains function . string-list: add pos to iterator callback . add functions for memory-efficient bitmaps . paint_down_to_common: use prio_queue . tag: factor out decision to stream tags . tag: allow --sort with -n Expecting a reroll. * ab/add-interactive-show-diff-func-name (2014-05-12) 2 commits - SQUASH??? git-add--interactive: Preserve diff heading when splitting hunks - git-add--interactive: Preserve diff heading when splitting hunks Waiting for a reroll. * jn/gitweb-utf8-in-links (2014-05-27) 1 commit - gitweb: Harden UTF-8 handling in generated links $gmane/250758? * rh/prompt-tests (2014-06-05) 11 commits - t9904: new __git_ps1 tests for Zsh - test-lib: make it possible to override how test code is eval'd -
Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)
From: Junio C Hamano gits...@pobox.com Sent: Wednesday, July 23, 2014 7:10 PM Philip Oakley philipoak...@iee.org writes: * po/everyday-doc (2014-01-27) 1 commit - Make 'git help everyday' work This may make the said command to emit something, but the source is not meant to be formatted into a manual pages to begin with, and also its contents are a bit stale. It may be a good first step in the right direction, but needs more work to at least get the mark-up right before public consumption. Will hold. It's not clear to me which bits of mark-up are 'wrong' and must be reworked, It's been too long since I wrote the above and I left it without updates (these comments are by default carried over from one issue to the next of What's cooking report, unless there is some development on the topic). Now I read the output (admittedly, I skimmed only the HTML version), I think the formatting / mark-up is fine. Thanks for the clarification - I hadn't been sure which way to go on the formatting aspect. I at the same time found various command sequences used there are rather classical and there are better ways to do the same with modern tools, I can have a look at the 'standalone' and 'participant' developer command lists but would shy away from any claims about the 'integrator' and 'administrator' roles ;-) which still makes me feel hesitant to promote this document without updating its contents, though. I hadn't viewed it as a 'promotion', rather it was simply ensuring access to the guide via the help system, instead of leaving it somewhat hidden. -- Philip -- 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: What's cooking in git.git (Jul 2014, #04; Tue, 22)
Philip Oakley philipoak...@iee.org writes: which still makes me feel hesitant to promote this document without updating its contents, though. I hadn't viewed it as a 'promotion', rather it was simply ensuring access to the guide via the help system, instead of leaving it somewhat hidden. Stale or incorrect pieces of advice that are hidden will not harm (non-)readers. Making them more available would mean giving them more chances to do harm ;-). -- 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 and Openssl license
Hi all, I'm a developer of Seafile (https://github.com/haiwen/seafile) project. We borrowed some source code from the Git project and are going to license our code in GPLv2. But one concern is that GPLv2 is not compatible with the Openssl license. It requires an exception. As far as I can see, Git also links with Openssl library. But I can't find an exception in the license of Git. So what I want to ask is that, is it safe for us to use Git's code and link with Openssl library? Thanks, - Johnathan -- 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 5/7] enforce `xfuncname` precedence over `funcname`
On 7/25/2014 2:52 AM, Ramsay Jones wrote: On 24/07/14 20:54, Junio C Hamano wrote: Tanay Abhra tanay...@gmail.com writes: If we take the easy way out, fixing UI mistakes would be easier, just replace git_config_cache() with git_config_raw() for such cases. I do not think that would fly well. The kind of let's migrate funcname users to xfuncname while still supporting the old uses change will be done in the callback functions like userdiff_config(). But it is very typical that multiple config callback functions are cascaded (e.g. many eventually end up calling git_default_core_config()); in order to a workaround you suggest to help a callback in deep in a cascade chain would require you to see which ones among all the callback functions will eventually call the callback you are updating for migration and update all git_config() calls to git_config_raw(). If you fix it properly (assuming it is feasible; I haven't heard if you even tried to see how much work it would involve), you do not need to introduce git_config_cached() (or _raw() for that matter), which is a huge plus. git_config() would instead do the right thing automatically, giving the same semantics except that it does not read the same file twice when it is known that the file has not changed. I haven't been following this conversation too closely, so if I have grasped the wrong end of this stick, please accept my apologies! ;-) Usually if you need to iterate the values in a hash-table in the order of key insertion, you would simply link the hash-table entries into a linked list. This assumes that the keys are distinct, or if not, that you are using a 'multi-map' type of hash-table. Here, if memory serves me, you are doing the 'multi' bit yourself within the single hash-table entry for a given key; so its not quite so easy. However, I think it you could create a list of pointer to hash-table entry, string-list index pairs in the config_set and use that to do the iteration. A bit ugly, but it should work. Thanks for the advice, that is exactly what I am doing. HTH 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: git feature-branch
On 07/25/2014 03:45 AM, Sheldon Els wrote: Hi A small tool I wrote that is useful for some workflows. I thought it'd be worth sharing. https://github.com/sheldon/git-feature-branch/ As far as I can tell it's just a shell script; does it really need installation instructions, and if so can they not be more generic than brew install? Speaking for myself I have NO clue what that is. -- 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 feature-branch
It is just a shell script yes, and a man page to make things a bit more discoverable for git help feature-branch. The brew command comes from homebrew, a popular OSX package manager. My platform of choice. Perhaps I can get support for an easy install for your platform. Do you think a Makefile that installs to /usr/local/bin and /usr/local/share/man would fit, or are you on windows? On 25 July 2014 05:11, Sitaram Chamarty sitar...@gmail.com wrote: On 07/25/2014 03:45 AM, Sheldon Els wrote: Hi A small tool I wrote that is useful for some workflows. I thought it'd be worth sharing. https://github.com/sheldon/git-feature-branch/ As far as I can tell it's just a shell script; does it really need installation instructions, and if so can they not be more generic than brew install? Speaking for myself I have NO clue what that is. -- 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
