Issue with 'git diff' and non ascii characters

[Giulio Cesare Solaroli]

Hello,

I have spotted a problem using 'git diff' when non ascii characters are 
involved.
Not sure if the problem is due to the name of the file, or its content.

Cheers,

Giulio Cesare

Steps to reproduce the problem:

$ sw_vers
ProductName:Mac OS X
ProductVersion: 10.9.4
BuildVersion:   13E28
$ git --version
git version 1.8.5.2 (Apple Git-48)
$ mkdir test
$ cd test
$ echo prova  tèst.md
$ git init
Initialized empty Git repository in /private/tmp/test/.git/
$ git add *
$ git commit -m first commit
[master (root-commit) ebbe2a3] first commit
 1 file changed, 1 insertion(+)
 create mode 100644 t\303\250st.md
$ echo provà  tèst.md 
$ git status
On branch master
Changes not staged for commit:
  (use git add file... to update what will be committed)
  (use git checkout -- file... to discard changes in working directory)

modified:   t\303\250st.md

no changes added to commit (use git add and/or git commit -a)
$ git diff tèst.md 
$ 

--
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 1/2] document irregular config --add behaviour for empty and NULL values

[Tanay Abhra]

If we have a config file like,
[foo]
baz
bar =

and we try something like, git config --add foo.baz roll, Git will
segfault. Moreover, for git config --add foo.bar roll, it will
overwrite the original value instead of appending after the existing
empty value. Document these deficiencies in form of a test.

Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Tanay Abhra tanay...@gmail.com
---

Sorry for this very late reply. I was stuck in a flood affected region
with no internet connectivity for the past week. I am safe now. :)

FWIW, here is the reroll with a set bit in the store struct and an exported
global. I could have done the reroll as you have done, but Jeff had mentioned
that he liked the version with a bit flag more. But you can choose the version
that seems better to you.

 t/t1303-wacky-config.sh | 20 
 1 file changed, 20 insertions(+)

diff --git a/t/t1303-wacky-config.sh b/t/t1303-wacky-config.sh
index 3a2c819..e5c0f07 100755
--- a/t/t1303-wacky-config.sh
+++ b/t/t1303-wacky-config.sh
@@ -111,4 +111,24 @@ test_expect_success 'unset many entries' '
test_must_fail git config section.key
 '

+test_expect_failure '--add appends new value after existing empty value' '
+   cat expect -\EOF 
+
+
+   fool
+   roll
+   EOF
+   cp .git/config .git/config.old 
+   test_when_finished mv .git/config.old .git/config 
+   cat .git/config -\EOF 
+   [foo]
+   baz
+   baz =
+   baz = fool
+   EOF
+   git config --add foo.baz roll 
+   git config --get-all foo.baz output 
+   test_cmp expect output
+'
+
 test_done
-- 
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 v2 2/2] make config --add behave correctly for empty and NULL values

[Tanay Abhra]

The problem lies with the regexp used for simulating --add in
`git_config_set_multivar_in_file()`, ^$, which in ideal case should
not match with any string but is true for empty strings. Instead use a
sentinel value CONFIG_REGEX_NONE to say we do not want to replace any
existing entry and use it in the implementation of git config --add.

For removing the segfault add a check for NULL values in `matches()` in
config.c.

Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
 builtin/config.c|  2 +-
 cache.h |  2 ++
 config.c| 21 +
 t/t1303-wacky-config.sh |  2 +-
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/builtin/config.c b/builtin/config.c
index aba7135..195664b 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -611,7 +611,7 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
check_argc(argc, 2, 2);
value = normalize_value(argv[0], argv[1]);
return git_config_set_multivar_in_file(given_config_source.file,
-  argv[0], value, ^$, 0);
+  argv[0], value, 
CONFIG_REGEX_NONE, 0);
}
else if (actions == ACTION_REPLACE_ALL) {
check_write();
diff --git a/cache.h b/cache.h
index dfa1a56..a09217d 100644
--- a/cache.h
+++ b/cache.h
@@ -1284,6 +1284,8 @@ extern int update_server_info(int);
 #define CONFIG_INVALID_PATTERN 6
 #define CONFIG_GENERIC_ERROR 7

+extern const char CONFIG_REGEX_NONE[];
+
 struct git_config_source {
unsigned int use_stdin:1;
const char *file;
diff --git a/config.c b/config.c
index 83c913a..20476e0 100644
--- a/config.c
+++ b/config.c
@@ -46,6 +46,8 @@ static int zlib_compression_seen;
  */
 static struct config_set the_config_set;

+const char CONFIG_REGEX_NONE[] = a^;
+
 static int config_file_fgetc(struct config_source *conf)
 {
return fgetc(conf-u.file);
@@ -1607,14 +1609,20 @@ static struct {
unsigned int offset_alloc;
enum { START, SECTION_SEEN, SECTION_END_SEEN, KEY_SEEN } state;
int seen;
+   unsigned value_never_matches:1;
 } store;

 static int matches(const char *key, const char *value)
 {
-   return !strcmp(key, store.key) 
-   (store.value_regex == NULL ||
-(store.do_not_match ^
- !regexec(store.value_regex, value, 0, NULL, 0)));
+   if (strcmp(key, store.key))
+   return 0; /* not ours */
+   if (!store.value_regex)
+   return 1; /* always matches */
+   if (store.value_never_matches)
+   return 0; /* never matches */
+
+   return store.do_not_match ^
+   (value  !regexec(store.value_regex, value, 0, NULL, 0));
 }

 static int store_aux(const char *key, const char *value, void *cb)
@@ -1876,6 +1884,8 @@ out_free_ret_1:
 /*
  * If value==NULL, unset in (remove from) config,
  * if value_regex!=NULL, disregard key/value pairs where value does not match.
+ * if value_regex==CONFIG_REGEX_NONE, do not match any existing values
+ * (only add a new one)
  * if multi_replace==0, nothing, or only one matching key/value is replaced,
  * else all matching key/values (regardless how many) are removed,
  * before the new pair is written.
@@ -1966,6 +1976,9 @@ int git_config_set_multivar_in_file(const char 
*config_filename,
} else
store.do_not_match = 0;

+   if (value_regex == CONFIG_REGEX_NONE)
+   store.value_never_matches = 1;
+
store.value_regex = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(store.value_regex, value_regex,
REG_EXTENDED)) {
diff --git a/t/t1303-wacky-config.sh b/t/t1303-wacky-config.sh
index e5c0f07..3b92083 100755
--- a/t/t1303-wacky-config.sh
+++ b/t/t1303-wacky-config.sh
@@ -111,7 +111,7 @@ test_expect_success 'unset many entries' '
test_must_fail git config section.key
 '

-test_expect_failure '--add appends new value after existing empty value' '
+test_expect_success '--add appends new value after existing empty value' '
cat expect -\EOF 


-- 
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

Re: [PATCH v3 6/6] Make sure that index-pack --strict checks tag objects

[Johannes Schindelin]

Hi Junio,

On Thu, 11 Sep 2014, Junio C Hamano wrote:

 Junio C Hamano gits...@pobox.com writes:
 
  When our toolset has become too tight without leaving enough escape
  hatch to hinder further development, it is very sensible to at least
  think about adding a new --for-debug option to hash-object and
  pack-objects that allows us to deliberately create broken
  datastreams to test against.
 
  [...]
 
 It wasn't too painful to do one of them, and the result looks rather
 nice.

I was loathe to make it easier for interested parties to create invalid
Git objects and to push them onto servers that cannot yet benefit from my
patch series. At the very least, I would have preferred to put such
functionality into test-* executables (where I searched for that
functionality in the first place), i.e. outside the distributed binaries.

But since you already did the work and it does the job, I won't worry
about it.

A bigger worry is that the additional test verifies that fsck catches the
invalid tag object and exits, when we really want to be certain that git
fetch --strict will abort on such an object. So the test is still
indirect, although I admit that it is closer now to what we want.

Version 4 of the patch series (without your hash-object --literally patch
because mailed patch series cannot declare on what branches from 'pu' they
rely, I always base my patch series on 'next' for that reason [*1*])
coming up.

Ciao,
Dscho

Footnote *1*: As always, I push my patch series to a topic branch on
GitHub. The one corresponding to the upcoming patch series is in
https://github.com/dscho/git/compare/next...fsck-tag, the one with your
additional test in
https://github.com/dscho/git/compare/next...fsck-tag-plus (the latter
being a thicket rather than a linear topic branch).
--
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 v4 2/6] Accept object data in the fsck_object() function

[Johannes Schindelin]

When fsck'ing an incoming pack, we need to fsck objects that cannot be
read via read_sha1_file() because they are not local yet (and might even
be rejected if transfer.fsckobjects is set to 'true').

For commits, there is a hack in place: we basically cache commit
objects' buffers anyway, but the same is not true, say, for tag objects.

By refactoring fsck_object() to take the object buffer and size as
optional arguments -- optional, because we still fall back to the
previous method to look at the cached commit objects if the caller
passes NULL -- we prepare the machinery for the upcoming handling of tag
objects.

The assumption that such buffers are inherently NUL terminated is now
wrong, of course, hence we pass the size of the buffer so that we can
add a sanity check later, to prevent running past the end of the buffer.

Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
 builtin/fsck.c   |  2 +-
 builtin/index-pack.c |  3 ++-
 builtin/unpack-objects.c | 14 ++
 fsck.c   | 24 +++-
 fsck.h   |  4 +++-
 5 files changed, 31 insertions(+), 16 deletions(-)

diff --git a/builtin/fsck.c b/builtin/fsck.c
index d42a27d..d9f4e6e 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -298,7 +298,7 @@ static int fsck_obj(struct object *obj)
 
if (fsck_walk(obj, mark_used, NULL))
objerror(obj, broken links);
-   if (fsck_object(obj, check_strict, fsck_error_func))
+   if (fsck_object(obj, NULL, 0, check_strict, fsck_error_func))
return -1;
 
if (obj-type == OBJ_TREE) {
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 5568a5b..f2465ff 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -773,7 +773,8 @@ static void sha1_object(const void *data, struct 
object_entry *obj_entry,
if (!obj)
die(_(invalid %s), typename(type));
if (do_fsck_object 
-   fsck_object(obj, 1, fsck_error_function))
+   fsck_object(obj, buf, size, 1,
+   fsck_error_function))
die(_(Error in object));
if (fsck_walk(obj, mark_link, NULL))
die(_(Not all child objects of %s are 
reachable), sha1_to_hex(obj-sha1));
diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
index 99cde45..855d94b 100644
--- a/builtin/unpack-objects.c
+++ b/builtin/unpack-objects.c
@@ -164,10 +164,10 @@ static unsigned nr_objects;
  * Called only from check_object() after it verified this object
  * is Ok.
  */
-static void write_cached_object(struct object *obj)
+static void write_cached_object(struct object *obj, struct obj_buffer *obj_buf)
 {
unsigned char sha1[20];
-   struct obj_buffer *obj_buf = lookup_object_buffer(obj);
+
if (write_sha1_file(obj_buf-buffer, obj_buf-size, 
typename(obj-type), sha1)  0)
die(failed to write object %s, sha1_to_hex(obj-sha1));
obj-flags |= FLAG_WRITTEN;
@@ -180,6 +180,8 @@ static void write_cached_object(struct object *obj)
  */
 static int check_object(struct object *obj, int type, void *data)
 {
+   struct obj_buffer *obj_buf;
+
if (!obj)
return 1;
 
@@ -198,11 +200,15 @@ static int check_object(struct object *obj, int type, 
void *data)
return 0;
}
 
-   if (fsck_object(obj, 1, fsck_error_function))
+   obj_buf = lookup_object_buffer(obj);
+   if (!obj_buf)
+   die(Whoops! Cannot find object '%s', sha1_to_hex(obj-sha1));
+   if (fsck_object(obj, obj_buf-buffer, obj_buf-size, 1,
+   fsck_error_function))
die(Error in object);
if (fsck_walk(obj, check_object, NULL))
die(Error on reachable objects of %s, sha1_to_hex(obj-sha1));
-   write_cached_object(obj);
+   write_cached_object(obj, obj_buf);
return 0;
 }
 
diff --git a/fsck.c b/fsck.c
index 56156ff..dd77628 100644
--- a/fsck.c
+++ b/fsck.c
@@ -277,7 +277,7 @@ static int fsck_ident(const char **ident, struct object 
*obj, fsck_error error_f
 }
 
 static int fsck_commit_buffer(struct commit *commit, const char *buffer,
- fsck_error error_func)
+   unsigned long size, fsck_error error_func)
 {
unsigned char tree_sha1[20], sha1[20];
struct commit_graft *graft;
@@ -322,15 +322,18 @@ static int fsck_commit_buffer(struct commit *commit, 
const char *buffer,
return 0;
 }
 
-static int fsck_commit(struct commit *commit, fsck_error error_func)
+static int fsck_commit(struct commit *commit, const char *data,
+   unsigned long size, fsck_error error_func)
 {
-   const char *buffer = get_commit_buffer(commit, NULL);
-   int ret = fsck_commit_buffer(commit, buffer, error_func);
-   unuse_commit_buffer(commit, 

[PATCH v4 3/6] Make sure fsck_commit_buffer() does not run out of the buffer

[Johannes Schindelin]

So far, we assumed that the buffer is NUL terminated, but this is not
a safe assumption, now that we opened the fsck_object() API to pass a
buffer directly.

So let's make sure that there is at least an empty line in the buffer.
That way, our checks would fail if the empty line was encountered
prematurely, and consequently we can get away with the current string
comparisons even with non-NUL-terminated buffers are passed to
fsck_object().

Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
 fsck.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/fsck.c b/fsck.c
index dd77628..73da6f8 100644
--- a/fsck.c
+++ b/fsck.c
@@ -237,6 +237,26 @@ static int fsck_tree(struct tree *item, int strict, 
fsck_error error_func)
return retval;
 }
 
+static int require_end_of_header(const void *data, unsigned long size,
+   struct object *obj, fsck_error error_func)
+{
+   const char *buffer = (const char *)data;
+   unsigned long i;
+
+   for (i = 0; i  size; i++) {
+   switch (buffer[i]) {
+   case '\0':
+   return error_func(obj, FSCK_ERROR,
+   unterminated header: NUL at offset %d, i);
+   case '\n':
+   if (i + 1  size  buffer[i + 1] == '\n')
+   return 0;
+   }
+   }
+
+   return error_func(obj, FSCK_ERROR, unterminated header);
+}
+
 static int fsck_ident(const char **ident, struct object *obj, fsck_error 
error_func)
 {
char *end;
@@ -284,6 +304,9 @@ static int fsck_commit_buffer(struct commit *commit, const 
char *buffer,
unsigned parent_count, parent_line_count = 0;
int err;
 
+   if (require_end_of_header(buffer, size, commit-object, error_func))
+   return -1;
+
if (!skip_prefix(buffer, tree , buffer))
return error_func(commit-object, FSCK_ERROR, invalid format 
- expected 'tree' line);
if (get_sha1_hex(buffer, tree_sha1) || buffer[40] != '\n')
-- 
2.0.0.rc3.9669.g840d1f9

--
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 v4 0/6] Improve tag checking in fsck and with transfer.fsckobjects

[Johannes Schindelin]

This patch series introduces detailed checking of tag objects when
calling git fsck, and also when transfer.fsckobjects is set to true.

To this end, the fsck machinery is reworked to accept the buffer and
size of the object to check, and for commit and tag objects, we verify
that the buffers contain an end of header (i.e. an empty line) to
guarantee that our checks do not run beyond the buffer.

This work was sponsored by GitHub.

Changes since v3:

- removed undesired negativity from commit message

- removed space in '2 err'

Johannes Schindelin (6):
  Refactor type_from_string() to avoid die()ing in case of errors
  Accept object data in the fsck_object() function
  Make sure fsck_commit_buffer() does not run out of the buffer
  fsck: check tag objects' headers
  Add regression tests for stricter tag fsck'ing
  Make sure that index-pack --strict checks tag objects

 builtin/fsck.c   |   2 +-
 builtin/index-pack.c |   3 +-
 builtin/unpack-objects.c |  14 +++--
 fsck.c   | 133 +++
 fsck.h   |   4 +-
 object.c |  11 +++-
 object.h |   3 +-
 t/t1450-fsck.sh  |  20 +++
 t/t5302-pack-index.sh|  19 +++
 9 files changed, 189 insertions(+), 20 deletions(-)

-- 
2.0.0.rc3.9669.g840d1f9
--
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 v4 1/6] Refactor type_from_string() to avoid die()ing in case of errors

[Johannes Schindelin]

In the next commits, we will enhance the fsck_tag() function to check
tag objects more thoroughly. To this end, we need a function to verify
that a given string is a valid object type, but that does not die() in
the negative case.

While at it, prepare type_from_string() for counted strings, i.e. strings
with an explicitly specified length rather than a NUL termination.

Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
 object.c | 11 +--
 object.h |  3 ++-
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/object.c b/object.c
index a16b9f9..aedac24 100644
--- a/object.c
+++ b/object.c
@@ -33,13 +33,20 @@ const char *typename(unsigned int type)
return object_type_strings[type];
 }
 
-int type_from_string(const char *str)
+int type_from_string_gently(const char *str, ssize_t len, int gentle)
 {
int i;
 
+   if (len  0)
+   len = strlen(str);
+
for (i = 1; i  ARRAY_SIZE(object_type_strings); i++)
-   if (!strcmp(str, object_type_strings[i]))
+   if (!strncmp(str, object_type_strings[i], len))
return i;
+
+   if (gentle)
+   return -1;
+
die(invalid object type \%s\, str);
 }
 
diff --git a/object.h b/object.h
index 5e8d8ee..e028ced 100644
--- a/object.h
+++ b/object.h
@@ -53,7 +53,8 @@ struct object {
 };
 
 extern const char *typename(unsigned int type);
-extern int type_from_string(const char *str);
+extern int type_from_string_gently(const char *str, ssize_t, int gentle);
+#define type_from_string(str) type_from_string_gently(str, -1, 0)
 
 /*
  * Return the current number of buckets in the object hashmap.
-- 
2.0.0.rc3.9669.g840d1f9

--
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 v4 4/6] fsck: check tag objects' headers

[Johannes Schindelin]

We inspect commit objects pretty much in detail in git-fsck, but we just
glanced over the tag objects. Let's be stricter.

Since we do not want to limit 'tag' lines unduly, values that would fail
the refname check only result in warnings, not errors.

Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
 fsck.c | 86 +-
 1 file changed, 85 insertions(+), 1 deletion(-)

diff --git a/fsck.c b/fsck.c
index 73da6f8..2fffa43 100644
--- a/fsck.c
+++ b/fsck.c
@@ -6,6 +6,7 @@
 #include commit.h
 #include tag.h
 #include fsck.h
+#include refs.h
 
 static int fsck_walk_tree(struct tree *tree, fsck_walk_func walk, void *data)
 {
@@ -355,6 +356,88 @@ static int fsck_commit(struct commit *commit, const char 
*data,
return ret;
 }
 
+static int fsck_tag_buffer(struct tag *tag, const char *data,
+   unsigned long size, fsck_error error_func)
+{
+   unsigned char sha1[20];
+   int ret = 0;
+   const char *buffer;
+   char *to_free = NULL, *eol;
+   struct strbuf sb = STRBUF_INIT;
+
+   if (data)
+   buffer = data;
+   else {
+   enum object_type type;
+
+   buffer = to_free =
+   read_sha1_file(tag-object.sha1, type, size);
+   if (!buffer)
+   return error_func(tag-object, FSCK_ERROR,
+   cannot read tag object);
+
+   if (type != OBJ_TAG) {
+   ret = error_func(tag-object, FSCK_ERROR,
+   expected tag got %s,
+   typename(type));
+   goto done;
+   }
+   }
+
+   if (require_end_of_header(buffer, size, tag-object, error_func))
+   goto done;
+
+   if (!skip_prefix(buffer, object , buffer)) {
+   ret = error_func(tag-object, FSCK_ERROR, invalid format - 
expected 'object' line);
+   goto done;
+   }
+   if (get_sha1_hex(buffer, sha1) || buffer[40] != '\n') {
+   ret = error_func(tag-object, FSCK_ERROR, invalid 'object' 
line format - bad sha1);
+   goto done;
+   }
+   buffer += 41;
+
+   if (!skip_prefix(buffer, type , buffer)) {
+   ret = error_func(tag-object, FSCK_ERROR, invalid format - 
expected 'type' line);
+   goto done;
+   }
+   eol = strchr(buffer, '\n');
+   if (!eol) {
+   ret = error_func(tag-object, FSCK_ERROR, invalid format - 
unexpected end after 'type' line);
+   goto done;
+   }
+   if (type_from_string_gently(buffer, eol - buffer, 1)  0)
+   ret = error_func(tag-object, FSCK_ERROR, invalid 'type' 
value);
+   if (ret)
+   goto done;
+   buffer = eol + 1;
+
+   if (!skip_prefix(buffer, tag , buffer)) {
+   ret = error_func(tag-object, FSCK_ERROR, invalid format - 
expected 'tag' line);
+   goto done;
+   }
+   eol = strchr(buffer, '\n');
+   if (!eol) {
+   ret = error_func(tag-object, FSCK_ERROR, invalid format - 
unexpected end after 'type' line);
+   goto done;
+   }
+   strbuf_addf(sb, refs/tags/%.*s, (int)(eol - buffer), buffer);
+   if (check_refname_format(sb.buf, 0))
+   error_func(tag-object, FSCK_WARN, invalid 'tag' name: %s, 
buffer);
+   buffer = eol + 1;
+
+   if (!skip_prefix(buffer, tagger , buffer))
+   /* early tags do not contain 'tagger' lines; warn only */
+   error_func(tag-object, FSCK_WARN, invalid format - expected 
'tagger' line);
+   else
+   ret = fsck_ident(buffer, tag-object, error_func);
+
+done:
+   strbuf_release(sb);
+   free(to_free);
+   return ret;
+}
+
 static int fsck_tag(struct tag *tag, const char *data,
unsigned long size, fsck_error error_func)
 {
@@ -362,7 +445,8 @@ static int fsck_tag(struct tag *tag, const char *data,
 
if (!tagged)
return error_func(tag-object, FSCK_ERROR, could not load 
tagged object);
-   return 0;
+
+   return fsck_tag_buffer(tag, data, size, error_func);
 }
 
 int fsck_object(struct object *obj, void *data, unsigned long size,
-- 
2.0.0.rc3.9669.g840d1f9

--
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 v4 5/6] Add regression tests for stricter tag fsck'ing

[Johannes Schindelin]

The intent of the new test case is to catch general breakages in
the fsck_tag() function, not so much to test it extensively, trying to
strike the proper balance between thoroughness and speed.

While it *would* have been nice to test the code path where fsck_object()
encounters an invalid tag object, this is not possible using git fsck: tag
objects are parsed already before fsck'ing (and the parser already fails
upon such objects).

Even worse: we would not even be able write out invalid tag objects
because git hash-object parses those objects, too, unless we resorted to
really ugly hacks such as using something like this in the unit tests
(essentially depending on Perl *and* Compress::Zlib):

hash_invalid_object () {
contents=$(printf '%s %d\0%s' $1 ${#2} $2) 
sha1=$(echo $contents | test-sha1) 
suffix=${sha1#??} 
mkdir -p .git/objects/${sha1%$suffix} 
echo $contents |
perl -MCompress::Zlib -e 'undef $/; print compress()' \
 .git/objects/${sha1%$suffix}/$suffix 
echo $sha1
}

Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
 t/t1450-fsck.sh | 20 
 1 file changed, 20 insertions(+)

diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index 8c739c9..2b6a6f2 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -194,6 +194,26 @@ test_expect_success 'tag pointing to something else than 
its type' '
test_must_fail git fsck --tags
 '
 
+test_expect_success 'tag with incorrect tag name  missing tagger' '
+   sha=$(git rev-parse HEAD) 
+   cat wrong-tag -EOF 
+   object $sha
+   type commit
+   tag wrong name format
+
+   This is an invalid tag.
+   EOF
+
+   tag=$(git hash-object -t tag -w --stdin wrong-tag) 
+   test_when_finished remove_object $tag 
+   echo $tag .git/refs/tags/wrong 
+   test_when_finished git update-ref -d refs/tags/wrong 
+   git fsck --tags 2out 
+   cat out 
+   grep invalid .tag. name out 
+   grep expected .tagger. line out
+'
+
 test_expect_success 'cleaned up' '
git fsck actual 21 
test_cmp empty actual
-- 
2.0.0.rc3.9669.g840d1f9

--
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 v4 6/6] Make sure that index-pack --strict checks tag objects

[Johannes Schindelin]

One of the most important use cases for the strict tag object checking
is when transfer.fsckobjects is set to true to catch invalid objects
early on. This new regression test essentially tests the same code path
by directly calling 'index-pack --strict' on a pack containing an
tag object without a 'tagger' line.

Technically, this test is not enough: it only exercises a code path that
*warns*, not one that *fails*. The reason is that hash-object and
pack-objects both insist on parsing the tag objects and would fail on
invalid tag objects at this time.

Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
 t/t5302-pack-index.sh | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
index 4bbb718..61bc8da 100755
--- a/t/t5302-pack-index.sh
+++ b/t/t5302-pack-index.sh
@@ -243,4 +243,23 @@ test_expect_success 'running index-pack in the object 
store' '
 test -f .git/objects/pack/pack-${pack1}.idx
 '
 
+test_expect_success 'index-pack --strict warns upon missing tagger in tag' '
+sha=$(git rev-parse HEAD) 
+cat wrong-tag EOF 
+object $sha
+type commit
+tag guten tag
+
+This is an invalid tag.
+EOF
+
+tag=$(git hash-object -t tag -w --stdin wrong-tag) 
+pack1=$(echo $tag $sha | git pack-objects tag-test) 
+echo remove tag object 
+thirtyeight=${tag#??} 
+rm -f .git/objects/${tag%$thirtyeight}/$thirtyeight 
+git index-pack --strict tag-test-${pack1}.pack 2err 
+grep ^error:.* expected .tagger. line err
+'
+
 test_done
-- 
2.0.0.rc3.9669.g840d1f9
--
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 config --add behave correctly for empty and NULL values

[Matthieu Moy]

Tanay Abhra tanay...@gmail.com writes:

 +const char CONFIG_REGEX_NONE[] = a^;

I have a slight preference for this version (no magic (void *)1 value,
and belts-and-suspenders solution since someone actually using the regex
should still get a correct behavior.

But I'm fine with both Junio/Peff's version or this one.

-- 
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 v4 06/32] lockfile: unlock file if lockfile permissions cannot be adjusted

[Michael Haggerty]

On 09/10/2014 12:39 AM, Junio C Hamano wrote:
 Michael Haggerty mhag...@alum.mit.edu writes:
 
 If the call to adjust_shared_perm() fails, lock_file returns -1, which
 to the caller looks like any other failure to lock the file.  So in
 this case, roll back the lockfile before returning so that the lock
 file is deleted immediately and the lockfile object is left in a
 predictable state (namely, unlocked).  Previously, the lockfile was
 retained until process cleanup in this situation.
 
 ... which would mean that other processes can grab a lock on the
 same file a bit earlier. Is there any negative implication caused by
 that difference?  I do not think of any but I could be missing
 something.

I think the end effect would be the same as if another process had
grabbed the lock a nanosecond before this process tried to do so. So
assuming that callers handle that situation correctly, I don't think
this change can cause any problems.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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 07/32] hold_lock_file_for_append(): release lock on errors

[Michael Haggerty]

On 09/10/2014 12:41 AM, Junio C Hamano wrote:
 Michael Haggerty mhag...@alum.mit.edu writes:
 
 If there is an error copying the old contents to the lockfile, roll
 back the lockfile before exiting so that the lockfile is not held
 until process cleanup.
 
 Same comment as 06/32 applies here.

Same reply applies here, too.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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 00/32] Lockfile correctness and refactoring

[Michael Haggerty]

On 09/10/2014 06:51 PM, Junio C Hamano wrote:
 [...]
 I am wondering if it makes sense to maintain a single ref that
 reaches all the commits in this shared object store repository,
 instead of keeping these millions of refs.  When you need to make
 more objects kept and reachable, create an octopus with the current
 tip and tips of all these refs that causes you to wish making these
 more objects kept and reachable.  Obviously that won't work well
 if the reason why your current scheme uses refs is because you
 adjust individual refs to prune some objects---hence the first
 question in this message.

This is an interesting idea.

I wouldn't trust git to handle efficiently commits with thousands of
parents, but it would be easy to knit a huge number of tips together
using multiple layers of, say, 16-parent octopus merges.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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 00/32] Lockfile correctness and refactoring

[Michael Haggerty]

On 09/10/2014 09:11 PM, Jeff King wrote:
 On Wed, Sep 10, 2014 at 09:51:03AM -0700, Junio C Hamano wrote:
 
 Jeff King p...@peff.net writes:

 Yes, we don't let normal fetchers see these repos. They're only for
 holding shared objects and the ref tips to keep them reachable.

 Are these individual refs have relations to the real world after
 they are created?  To ask it another way, let's say that a branch in
 a repository, which is using this as a shared object store, caused
 one of these refs to be created; now the origin repository rewinds
 or deletes that branch---do you do anything to the ref in the shared
 object store at that point?
 
 Yes, we fetch from them before doing any maintenance in the shared
 repository (like running repack). That's how objects migrate into the
 shared repository, as well.
 
 I am wondering if it makes sense to maintain a single ref that
 reaches all the commits in this shared object store repository,
 instead of keeping these millions of refs.  When you need to make
 more objects kept and reachable, create an octopus with the current
 tip and tips of all these refs that causes you to wish making these
 more objects kept and reachable.  Obviously that won't work well
 if the reason why your current scheme uses refs is because you
 adjust individual refs to prune some objects---hence the first
 question in this message.
 
 Exactly. You could do this if you threw away and re-made the octopus
 after each fetch (and then threw away the individual branches that went
 into it). For that matter, if all you really want are the tips for
 reachability, you can basically run for-each-ref | sort -u; most of
 these refs are tags that are duplicated between each fork.
 
 However, having the individual tips does make some things easier. If I
 only keep unique tips and I drop a tip from fork A, I would then need to
 check every other fork to see if any other fork has the same tip. OTOH,
 that means visiting N packed-refs files, each with (let's say) 3000
 refs. As opposed to dealing with a packed-refs file with N*3000 refs. So
 it's really not that different.

I think it would make more sense to have one octopus per fork, rather
than one octopus for all of the forks. The octopus for a fork could be
discarded and re-created every time that fork changed, without having to
worry about which of the old tips is still reachable from another fork.
In fact, if you happen to know that a particular update to a fork is
pure fast-forward, you could update the fork octopus by merging the
changed tips into the old fork octopus without having to re-knit all of
the unchanged tips together again.

The shared repository would need one reference per fork--still much
better than a reference for every reference in every fork. If even that
is too many references, you could knit the fork octopuses into an
overall octopus for all forks. But then updating that octopus for a
change to a fork would become more difficult, because you would have to
read the octopuses for the N-1 unchanged forks from the old octopus and
knit those together with the new octopus for the modified fork.

But all this imagineering doesn't mitigate the other reasons you list
below for not wanting to guarantee reachability using this trick.

 We also use the individual ref tips for packing. They factor into the
 bitmap selection, and we have some patches (which I've been meaning to
 upstream for a while now) to make delta selections in the shared-object
 repository that will have a high chance of reuse in clones of individual
 forks. And it's useful to query them for various reasons (e.g., who is
 referencing this object?).
 [...]

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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 00/32] Lockfile correctness and refactoring

[Michael Haggerty]

On 09/07/2014 04:21 PM, Torsten Bögershausen wrote:
 
 On 2014-09-06 09.50, Michael Haggerty wrote:
 Sorry for the long delay since v3. This version mostly cleans up a
 couple more places where the lockfile object was left in an
 ill-defined state. 
 No problem with the delay.
 The most important question is if we do the lk-active handling right.
 Set it to false as seen as possible, and to true as late as possible,
 then die() cleanly.
 So the -acive handling looks (more or less, please see below) and
 deserves another critical review, may be.
 
 Instead of commenting each patch, I collected a mixture of small questions
 and possible suggestions into a diff file.
 
 diff --git a/lockfile.c b/lockfile.c
 index e54d260..7f27ea2 100644
 --- a/lockfile.c
 +++ b/lockfile.c
 @@ -18,6 +18,10 @@
   *Usually, if $FILENAME is a symlink, then it is resolved, and the
   *file ultimately pointed to is the one that is locked and later
   *replaced.  However, if LOCK_NODEREF is used, then $FILENAME
 +LOCK_NODEREF can be read either as
 +LOCK_NODE_REF or LOCK_NO_DEREF
 +should we change it ?
 +

Good idea.

   *itself is locked and later replaced, even if it is a symlink.
   *
   * 2. Write the new file contents to the lockfile.
 @@ -46,9 +50,18 @@
   *   state:
   *   - the lockfile exists
   *   - active is set
 - *   - filename holds the filename of the lockfile
 + *   - filename holds the filename of the lockfile in a strbuf

I don't think this is necessary. The point of this list is to describe
the state machine, not the contents of the lock_file structure, so this
detail is only a distraction. And even if a reader is confused, the
compiler will warn if he tries to use the strbuf as if it were a string.

   *   - fd holds a file descriptor open for writing to the lockfile
   *   - owner holds the PID of the process that locked the file
 +question: Why do we need the PID here ?
 +Do we open a lock file and do a fork() ?
 +And if yes, the child gets a new PID, what happens when the
 +child gets a signal ?
 +Who owns the lockfile, the parent, the child, both ?
 +The child has access to all data, the fd is open and can be used,
 +why do we not allow a rollback, when the child dies ?

Good questions. I will add an explanation of the purpose of the pid in
this docstring.

   *
   * - Locked, lockfile closed (after close_lock_file()).  Same as the
   *   previous state, except that the lockfile is closed and fd is -1.
 @@ -57,7 +70,7 @@
   *   rollback_lock_file(), or a failed attempt to lock).  In this
   *   state:
   *   - active is unset
 - *   - filename is the empty string (usually, though there are
 + *   - filename is an empty string buffer (usually, though there are
   * transitory states in which this condition doesn't hold)
   *   - fd is -1
   *   - the object is left registered in the lock_file_list, and
 @@ -68,7 +81,7 @@
  
  static struct lock_file *volatile lock_file_list;
  
 -static void remove_lock_file(void)
 +static void remove_lock_files(void)

Good idea. I will rename these two functions.

  {
  pid_t me = getpid();
  
 @@ -79,9 +92,9 @@ static void remove_lock_file(void)
  }
  }
  
 -static void remove_lock_file_on_signal(int signo)
 +static void remove_lock_files_on_signal(int signo)
  {
 -remove_lock_file();
 +remove_lock_files();
  sigchain_pop(signo);
  raise(signo);
  }
 @@ -93,7 +106,7 @@ static void remove_lock_file_on_signal(int signo)
   * /, if any).  If path is empty or the root directory (/), set
   * path to the empty string.
   */
 -static void trim_last_path_elm(struct strbuf *path)
 +static void trim_last_path_elem(struct strbuf *path)

I agree that the old name was bad. I will make it even more explicit:
trim_last_path_component().

  {
  int i = path-len;
  
 @@ -143,7 +156,7 @@ static void resolve_symlink(struct strbuf *path)
   * link is a relative path, so replace the
   * last element of p with it.
   */
 -trim_last_path_elm(path);
 +trim_last_path_elem(path);
  
  strbuf_addbuf(path, link);
  }
 @@ -153,13 +166,16 @@ static void resolve_symlink(struct strbuf *path)
  /* Make sure errno contains a meaningful value on error */
  static int lock_file(struct lock_file *lk, const char *path, int flags)
  {
 +struct stat st;
 +int mode = 0666;
  if (!lock_file_list) {
  /* One-time initialization */
 -sigchain_push_common(remove_lock_file_on_signal);
 -atexit(remove_lock_file);
 +sigchain_push_common(remove_lock_files_on_signal);
 +atexit(remove_lock_files);
  }
  
 -assert(!lk-active);
 +  if (lk-active)
 +die(lk-active %s, path);

OK, but I will use die(BUG:...) since this would be an indication of a
bug in git.

  if (!lk-on_list) {
  /* Initialize *lk and add it to lock_file_list: */
 @@ -167,16 +183,25 @@ static int lock_file(struct lock_file *lk, const char 
 *path, int flags)
  

Re: Diffs for submodule conflicts during rebase usually empty

[Edward Z. Yang]

Hello Jens,

Excerpts from Jens Lehmann's message of 2014-09-11 15:29:28 -0400:
 Git does know what's going on, just fails to display it properly
 in the diff, as the output of ls-files shows:
 
 $git ls-files -u
 16 6a6e215138b7f343fba67ba1b6ffc152019c6085 1b
 16 fc12d3455b120916ec508c3ccd04f23957c08ea5 2b
 16 33d9fa9f9e25de2a85f84993d8f6c752f84c769a 3b

Right. But I'd also add that even though Git knows what's going
on, even if we reported /that/ it wouldn't be user friendly:
namely, because submodules are not updated automatically so the
first line would always be what the submodule was pointed to
before we started rebasing.  That's not so useful either...

 I agree that this needs to be improved, but am currently lacking
 the time to do it myself. But I believe this will get important
 rather soonish when we recursively update submodules too ...

As I've said, I'm happy to contribute a patch, if we can agree
what the right resolution is...

Cheers,
Edward
--
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-diff-tree --root

[Roman Neuhauser]

hello,

git-diff-tree without --root is absolutely silent for the root commit,
and i see no bad effects of --root on non-root commits.  are there any
hidden gotchas?  IOW, why is the --root behavior not the default?

cram[1] testcase::

  $ git init -q scratch
  $ cd scratch
  $ echo '.*.sw?'  .gitignore
  $ git add .gitignore
  $ git commit -q -m init .gitignore

  $ git diff-tree HEAD

  $ git diff-tree --root HEAD
  [0-9a-z]{40} (re)
  :00 100644  [0-9a-z]{40} A\\t.* 
(re)

[1] https://pypi.python.org/pypi/cram

-- 
roman
--
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-new-workdir submodules interact poorly with core.worktree

[Edward Z. Yang]

tl;dr You can't git-new-workdir checkouts which use core.worktree.  This
is unfortunate because 'git submodule init' uses core.worktree by
default, which means you can't recursively git-new-workdir without a
hack.

In the beginning, the Developer created the remote Git repository and
the submodule.

mkdir -p remote/sub
(cd remote/sub  git init  touch a  git add a  git commit -m sub 
init)
mkdir remote/top
cd remote/top
git init
git submodule add ../sub
git commit -m top init
cd ../..

And the Developer said, Let there be a local clone and submodule, and
lo, there was a local clone and submodule:

git clone remote/top top
(cd top  git submodule init  git submodule update)

the Developer blessed the working copy, and said Be fruitful and
increase in number with git-new-workdir:

git-new-workdir top worktop

Unfortunately, this workdir didn't have the submodules initialized.

$ ls worktop/sub/
$

Now, the Developer could have run:

$ (cd worktop  git submodule init  git submodule update)

but the resulting submodule would not have been shared with the original
submodule, in the same way that git-new-workdir shared the Git metadata.

The Developer sought to create the submodule in its own likeness, but it
did not work:

$ rmdir worktop/sub  git-new-workdir top/sub worktop/sub
fatal: Could not chdir to '../../../sub': No such file or directory

What was the Developer's fall from grace?  A glance at the config of
the original and new submodule shed light on the matter:

$ cat top/sub/.git
gitdir: ../.git/modules/sub
$ cat top/.git/modules/sub/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
worktree = ../../../sub
$ cat worktop/sub/.git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
worktree = ../../../sub

git-new-workdir sought to reuse the config of top/sub/.git, but this
configuration had core.worktree set.  For the original checkout,
this worked fine, since its location was .git/modules/sub; but for the
new workdir, this relative path was nonsense.

I do not think there is really a way to make this work with
core.worktree.  Our saving grace, however, is there is a hack that can
make this work: we just need to use the
pre-501770e1bb5d132ae4f79aa96715f07f6b84e1f6 style of cloning
submodules:

git clone remote/top oktop
git clone remote/sub oktop/sub
(cd oktop  git submodule init  git submodule update)

Now recursive git-new-workdir will work.

What's the upshot?  I propose two new features:

1. A flag for git submodule update which reverts to the old behavior
of making a seperate .git directory rather than collecting them together
in the top-level .git/modules

2. Teach git-new-workdir to complain if core.worktree is set in the
source config, and how to recursively copy submodules.

What do peopl think?

Thanks,
Edward
--
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 00/32] Lockfile correctness and refactoring

[Michael Haggerty]

On 09/10/2014 10:13 AM, Jeff King wrote:
 [...]
 I did coincidentally have an interesting experience with our lockfile
 code earlier today, which I'd like to relate.
 
 I was running pack-refs on a repository with a very large number of
 loose refs (about 1.8 million). [...] Each call to lock_ref_sha1_basic
 allocates a struct lock_file, which then gets added to the global
 lock_file list. Each one contains a fixed PATH_MAX buffer (4K on this
 machine). After we're done updating the ref, we leak the lock_file
 struct, since there's no way to remove it from the list.
 
 As a result, git tried to allocate 7G of RAM and got OOM-killed (the
 machine had only 8G). In addition to thrashing the disk even harder,
 since there was no room left for disk cache while we touched millions of
 loose refs. :)
 
 Your change in this series to use a strbuf would make this a lot better.
 But I still wonder how hard it would be to just remove lock_file structs
 from the global list when they are committed or rolled back. That would
 presumably also make the avoid transitory valid states patch from your
 series a bit easier, too (you could prepare the lockfile in peace, and
 then link it in fully formed, and do the opposite when removing it).
 
 I think with your strbuf patch, this leak at least becomes reasonable.
 So maybe it's not worth going further. But I'd be interested to hear
 your thoughts since you've been touching the area recently.

I've thought about this too, but it didn't seem to be worth the effort.
(Though your use case certainly adds a bit of justification.)

To make that change, we would have to remove entries from the list of
lock_file objects in a way that the code can be interrupted at any time
by a signal while leaving it in a state that is traversable by the
signal handler.

I think that can be done pretty easily with a singly-linked list. But
with a singly-linked list, we would have to iterate through the list to
find the node that needs to be removed. This could get expensive if
there are a lot of nodes in the list (see below).

So we would probably want to switch to using a doubly-linked list. I
think this would also be fairly simple, given that the signal handler
only needs to iterate through the list in a single direction. You'd just
have to be careful about adjusting the pointers in the right order to
let (say) a forwards traversal always work.

Then the callers who use heap-allocated lock_file objects would have to
be changed to free them when they're done with them, probably using a
special function that releases the strbufs, too. Callers using
statically-allocated lock_file objects would probably not have to be
changed.

But...

The ref-transaction code is, I think, moving in the direction of
updating all references in a single transaction. This means that we
would need to hold locks for all of the references at once anyway. So it
might be all for naught.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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 0/2] describe: support the syntax --abbrev=+

[Jonh Wendell]

Sometimes it's interesting to have a simple output that answers the question:
Are there commits after the latest tag?

One possible solution is to just print a + (plus) signal after the tag. 
Example:

 git describe --abbrev=1 5261ec5d5
v2.1.0-rc1-2-g5261ec

 git describe --abbrev=+ 5261ec5d5
v2.1.0-rc1+

First patch was sent in Aug 23, re-sending with Signed-off-by and
CC'ing Junio.

Jonh Wendell (2):
  describe: support the syntax --abbrev=+
  describe: Add documentation for --abbrev=+

 Documentation/git-describe.txt |  6 ++
 builtin/describe.c | 26 +-
 2 files changed, 27 insertions(+), 5 deletions(-)

-- 
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

[PATCH 1/2] describe: support the syntax --abbrev=+

[Jonh Wendell]

It will print just a + sign appended to the found tag, if there
are commits between the tag and the supplied commit.

It's useful when you just need a simple output to know if the
supplied commit is an exact match or not.

Signed-off-by: Jonh Wendell jonh.wend...@gmail.com
---
 builtin/describe.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/builtin/describe.c b/builtin/describe.c
index ee6a3b9..3a5c052 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -30,6 +30,7 @@ static int have_util;
 static const char *pattern;
 static int always;
 static const char *dirty;
+static int simple_abbrev = 0;
 
 /* diff-index command arguments to check if working tree is dirty. */
 static const char *diff_index_args[] = {
@@ -378,8 +379,12 @@ static void describe(const char *arg, int last_one)
}
 
display_name(all_matches[0].name);
-   if (abbrev)
-   show_suffix(all_matches[0].depth, cmit-object.sha1);
+   if (abbrev) {
+   if (simple_abbrev)
+   printf(+);
+   else
+   show_suffix(all_matches[0].depth, cmit-object.sha1);
+   }
if (dirty)
printf(%s, dirty);
printf(\n);
@@ -388,6 +393,16 @@ static void describe(const char *arg, int last_one)
clear_commit_marks(cmit, -1);
 }
 
+static int parse_opt_abbrev_for_describe_cb(const struct option *opt, const 
char *arg, int unset)
+{
+   if (arg  !strncmp(arg, +, 1)) {
+   simple_abbrev = 1;
+   return 0;
+   }
+
+   return parse_opt_abbrev_cb(opt, arg, unset);
+}
+
 int cmd_describe(int argc, const char **argv, const char *prefix)
 {
int contains = 0;
@@ -398,7 +413,6 @@ int cmd_describe(int argc, const char **argv, const char 
*prefix)
OPT_BOOL(0, tags,   tags, N_(use any tag, even 
unannotated)),
OPT_BOOL(0, long,   longformat, N_(always use long 
format)),
OPT_BOOL(0, first-parent, first_parent, N_(only follow 
first parent)),
-   OPT__ABBREV(abbrev),
OPT_SET_INT(0, exact-match, max_candidates,
N_(only output exact matches), 0),
OPT_INTEGER(0, candidates, max_candidates,
@@ -410,6 +424,8 @@ int cmd_describe(int argc, const char **argv, const char 
*prefix)
{OPTION_STRING, 0, dirty,  dirty, N_(mark),
N_(append mark on dirty working tree (default: 
\-dirty\)),
PARSE_OPT_OPTARG, NULL, (intptr_t) -dirty},
+   {OPTION_CALLBACK, 0, abbrev, abbrev, N_(n), N_(use n 
digits to display SHA-1s),
+   PARSE_OPT_OPTARG, parse_opt_abbrev_for_describe_cb, 0},
OPT_END(),
};
 
@@ -425,8 +441,8 @@ int cmd_describe(int argc, const char **argv, const char 
*prefix)
 
save_commit_buffer = 0;
 
-   if (longformat  abbrev == 0)
-   die(_(--long is incompatible with --abbrev=0));
+   if (longformat  (abbrev == 0 || simple_abbrev))
+   die(_(--long is incompatible with --abbrev=+ or --abbrev=0));
 
if (contains) {
struct argv_array args;
-- 
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

[PATCH 2/2] describe: Add documentation for --abbrev=+

[Jonh Wendell]

Signed-off-by: Jonh Wendell jonh.wend...@gmail.com
---
 Documentation/git-describe.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index d20ca40..e291770 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -54,6 +54,12 @@ OPTIONS
abbreviated object name, use n digits, or as many digits
as needed to form a unique object name.  An n of 0
will suppress long format, only showing the closest tag.
+   +
+   +
+   A special case of n equals to \+ (without quotes) will print
+   just a + sign instead of the whole suffix. This is useful if you
+   only need to know if the supplied commit-ish points to an exact
+   match or if there are commits between the tag found and the 
commit-ish.
 
 --candidates=n::
Instead of considering only the 10 most recent tags as
-- 
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 v4 10/32] cache.h: define constants LOCK_SUFFIX and LOCK_SUFFIX_LEN

[Michael Haggerty]

On 09/12/2014 12:15 AM, Ronnie Sahlberg wrote:
 On Sat, Sep 6, 2014 at 12:50 AM, Michael Haggerty mhag...@alum.mit.edu 
 wrote:
 There are a few places that use these values, so define constants for
 them.

 Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
 ---
  cache.h|  4 
  lockfile.c | 11 ++-
  refs.c |  7 ---
  3 files changed, 14 insertions(+), 8 deletions(-)

 diff --git a/cache.h b/cache.h
 index da77094..41d829b 100644
 --- a/cache.h
 +++ b/cache.h
 @@ -569,6 +569,10 @@ extern void fill_stat_cache_info(struct cache_entry 
 *ce, struct stat *st);
  #define REFRESH_IN_PORCELAIN   0x0020  /* user friendly output, not needs 
 update */
  extern int refresh_index(struct index_state *, unsigned int flags, const 
 struct pathspec *pathspec, char *seen, const char *header_msg);

 +/* String appended to a filename to derive the lockfile name: */
 +#define LOCK_SUFFIX .lock
 +#define LOCK_SUFFIX_LEN 5
 +
  struct lock_file {
 struct lock_file *next;
 int fd;
 diff --git a/lockfile.c b/lockfile.c
 index 964b3fc..bfea333 100644
 --- a/lockfile.c
 +++ b/lockfile.c
 @@ -176,10 +176,11 @@ static char *resolve_symlink(char *p, size_t s)
  static int lock_file(struct lock_file *lk, const char *path, int flags)
  {
 /*
 -* subtract 5 from size to make sure there's room for adding
 -* .lock for the lock file name
 +* subtract LOCK_SUFFIX_LEN from size to make sure there's
 +* room for adding .lock for the lock file name:
  */
 -   static const size_t max_path_len = sizeof(lk-filename) - 5;
 +   static const size_t max_path_len = sizeof(lk-filename) -
 +  LOCK_SUFFIX_LEN;

 if (!lock_file_list) {
 /* One-time initialization */
 @@ -204,7 +205,7 @@ static int lock_file(struct lock_file *lk, const char 
 *path, int flags)
 strcpy(lk-filename, path);
 if (!(flags  LOCK_NODEREF))
 resolve_symlink(lk-filename, max_path_len);
 -   strcat(lk-filename, .lock);
 +   strcat(lk-filename, LOCK_SUFFIX);
 lk-fd = open(lk-filename, O_RDWR | O_CREAT | O_EXCL, 0666);
 if (0 = lk-fd) {
 lk-owner = getpid();
 @@ -314,7 +315,7 @@ int commit_lock_file(struct lock_file *lk)
 if (lk-fd = 0  close_lock_file(lk))
 return -1;
 strcpy(result_file, lk-filename);
 -   i = strlen(result_file) - 5; /* .lock */
 +   i = strlen(result_file) - LOCK_SUFFIX_LEN; /* .lock */
 
 Not a new bug since the previous code is broken too.
 Should probably checkstrlen(result_file) = 5 here before subtracting 5.
 
 Otherwise, a caller that calls commit_lock_file() with an already
 committed/closed  lock_file can cause writing outside the bounds of
 the array on the line below.

Good catch; thanks. I will fix this in the reroll (though probably in a
later patch).

 [...]

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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] pretty-format: add append line-feed format specifier

[Junio C Hamano]

Jeff King p...@peff.net writes:

 I dunno. I wrote that original set of lua pretty-format patches to try
 to stop the insanity once and for all. But I realized that I do not
 actually want to do anything complicated with the output formats, and
 --oneline and a few simple --format calls usually are enough.

Yeah, I share that exactly, and %+ and friends are meant to be on
this side of the line between a few simple and complicated.  I
was not sure which side %if() falls myself, and while I still am not
sure, if I were asked to decide which today, I would probably say it
is on the simple side.
--
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 10/32] cache.h: define constants LOCK_SUFFIX and LOCK_SUFFIX_LEN

[Michael Haggerty]

On 09/12/2014 12:42 AM, Ronnie Sahlberg wrote:
 Maybe we should not have a public constant defined for the length :
 +#define LOCK_SUFFIX_LEN 5
 
 since it encourages unsafe code like :  (this was unsafe long before
 your patch so not a regression)
 +   i = strlen(result_file) - LOCK_SUFFIX_LEN; /* .lock */
 result_file[i] = 0;
 
 
 
 What about removing LOCK_SUFFIX_LEN from the public API and introduce
 a helper function something like :
 
 
 /* pointer to the character where the lock suffix starts */
 char *lock_suffix_ptr_safe(const char *filename)
 {
 size_t len = strlen(filename);
 if (len  5)
die(BUG:...
 if (strcmp(filename + len - 5, LOCK_SUFFIX)
die(BUG:...
 return filename + len - 5;
 }
 
 and use it instead?

At the end of this patch series, LOCK_SUFFIX_LEN is only used in two
places outside of lockfile.c:

* In check_refname_component(), to ensure that no component of a
reference name ends with .lock. This only indirectly has anything to
do with lockfiles.

* In delete_ref_loose(), to derive the name of the loose reference file
from the name of the lockfile. It immediately xmemdupz()s the part of
the filename that it needs, so it is kosher.

I will add a function get_locked_file_path() for the use of the second
caller.

I like being able to use the symbolic constant at the first caller, and
it is not dangerous. I don't think it is so important to make the
constant private, because I think somebody programming sloppily wouldn't
be deterred for long by not seeing a symbolic constant for the suffix
length. So if it's OK with you I'll leave the constant.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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 config --add behave correctly for empty and NULL values

[Junio C Hamano]

Matthieu Moy matthieu@grenoble-inp.fr writes:

 Tanay Abhra tanay...@gmail.com writes:

 +const char CONFIG_REGEX_NONE[] = a^;

 I have a slight preference for this version (no magic (void *)1 value,
 and belts-and-suspenders solution since someone actually using the regex
 should still get a correct behavior.

 But I'm fine with both Junio/Peff's version or this one.

I do not care too deeply either way, to be honest.

But if we were to redo this in the right way, I suspect that the
best solution may be to correct the root cause, which is the design
mistake in the git_config_set_multivar_in_file API.  The function
takes a regexp (possibly NULL) and a multi_replace bit, and with
that expresses these three combinations:

- a non-NULL regexp means only the existing ones that match are
  subject to replacement;

- NULL regexp means all of the existing ones that match are
  subject to replacement;

- multi-replace bit controls which ones among the replacement
  candidates are replaced (either the first one or all).

But we actually want to express three, not two, different handling
for the existing entries.  Either (1) use the regexp to decide which
ones are subject to replacement, (2) declare all of them are subject
to replacement, or (3) declare none of them are to be replaced.  The
last one cannot be expressed without coming up with a trick to say
I am giving a regexp that hopefully will not match anything as a
workaround because otherwise you will replace all of them but what I
really want to say is I do not want you to replace anything, and
this thread discusses a fix to the bug in the implementation that
failed to come up with a hopefully will not match anything
pattern.  And we are still discussing to fix a better workaround.

Instead of polishing the workaround, wouldn't it be better to make
it unnecessary to work it around?  For exaple, we could turn the
last parameter to the function into an unsigned flag with two
bits, CONFIG_SET_USE_REGEXP_TO_FILTER (if set, use the regexp to
filter which of the existing entries to be replaced) and
CONFIG_SET_REPLACE_MULTI (if set, replace all the eligible ones),
and the result would be conceptually a lot cleaner, no?

Some notes:

 - Because most callers expect replace behaviour, instead of
   adding CONFIG_SET_USE_REGEXP_TO_FILTER to the majority of
   existing callers, a new flag CONFIG_SET_JUST_APPEND (which is
   exactly the negation of the USE_REGEXP_TO_FILTER) would be a more
   practical thing to introduce.

 - We can keep using value_regexp==NULL (under !JUST_APPEND) to mean
   value_regexp=.*, i.e. matches anything, as a short-hand.

Hmm?
--
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-diff-tree --root

[Junio C Hamano]

Roman Neuhauser neuhau...@sigpipe.cz writes:

 git-diff-tree without --root is absolutely silent for the root commit,
 and i see no bad effects of --root on non-root commits.  are there any
 hidden gotchas?  IOW, why is the --root behavior not the default?

Because tools that was written before you proposed that change
expect to see nothing for the root commit, and then you are suddenly
breaking their expectations?
--
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 10/32] cache.h: define constants LOCK_SUFFIX and LOCK_SUFFIX_LEN

[Ronnie Sahlberg]

On Fri, Sep 12, 2014 at 10:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
 On 09/12/2014 12:42 AM, Ronnie Sahlberg wrote:
 Maybe we should not have a public constant defined for the length :
 +#define LOCK_SUFFIX_LEN 5

 since it encourages unsafe code like :  (this was unsafe long before
 your patch so not a regression)
 +   i = strlen(result_file) - LOCK_SUFFIX_LEN; /* .lock */
 result_file[i] = 0;



 What about removing LOCK_SUFFIX_LEN from the public API and introduce
 a helper function something like :


 /* pointer to the character where the lock suffix starts */
 char *lock_suffix_ptr_safe(const char *filename)
 {
 size_t len = strlen(filename);
 if (len  5)
die(BUG:...
 if (strcmp(filename + len - 5, LOCK_SUFFIX)
die(BUG:...
 return filename + len - 5;
 }

 and use it instead?

 At the end of this patch series, LOCK_SUFFIX_LEN is only used in two
 places outside of lockfile.c:

 * In check_refname_component(), to ensure that no component of a
 reference name ends with .lock. This only indirectly has anything to
 do with lockfiles.

 * In delete_ref_loose(), to derive the name of the loose reference file
 from the name of the lockfile. It immediately xmemdupz()s the part of
 the filename that it needs, so it is kosher.

 I will add a function get_locked_file_path() for the use of the second
 caller.

 I like being able to use the symbolic constant at the first caller, and
 it is not dangerous. I don't think it is so important to make the
 constant private, because I think somebody programming sloppily wouldn't
 be deterred for long by not seeing a symbolic constant for the suffix
 length. So if it's OK with you I'll leave the constant.

It is OK with me.
--
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] t9300: use cmp instead of test_cmp to compare binary files

[Johannes Sixt]

test_cmp is intended to produce diff output for human consumption. The
input in one instance in t9300-fast-import.sh are binary files, however.
Use cmp to compare the files.

This was noticed because on Windows we have a special implementation of
test_cmp in pure bash code (to ignore differences due to intermittent CR
in actual output), and bash runs into an infinite loop due to the binary
nature of the input.

Signed-off-by: Johannes Sixt j...@kdbg.org
---
 t/t9300-fast-import.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 99f5161..4b13170 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -2687,7 +2687,7 @@ test_expect_success 'R: verify created pack' '
 test_expect_success \
'R: verify written objects' \
'git --git-dir=R/.git cat-file blob big-file:big1 actual 
-test_cmp expect actual 
+cmp expect actual 
 a=$(git --git-dir=R/.git rev-parse big-file:big1) 
 b=$(git --git-dir=R/.git rev-parse big-file:big2) 
 test $a = $b'
-- 
2.0.0.12.gbcf935e

--
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] t9300: use cmp instead of test_cmp to compare binary files

[Junio C Hamano]

Johannes Sixt j...@kdbg.org writes:

 test_cmp is intended to produce diff output for human consumption. The
 input in one instance in t9300-fast-import.sh are binary files, however.
 Use cmp to compare the files.

Thanks.


 This was noticed because on Windows we have a special implementation of
 test_cmp in pure bash code (to ignore differences due to intermittent CR
 in actual output), and bash runs into an infinite loop due to the binary
 nature of the input.

 Signed-off-by: Johannes Sixt j...@kdbg.org
 ---
  t/t9300-fast-import.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
 index 99f5161..4b13170 100755
 --- a/t/t9300-fast-import.sh
 +++ b/t/t9300-fast-import.sh
 @@ -2687,7 +2687,7 @@ test_expect_success 'R: verify created pack' '
  test_expect_success \
   'R: verify written objects' \
   'git --git-dir=R/.git cat-file blob big-file:big1 actual 
 -  test_cmp expect actual 
 +  cmp expect actual 
a=$(git --git-dir=R/.git rev-parse big-file:big1) 
b=$(git --git-dir=R/.git rev-parse big-file:big2) 
test $a = $b'
--
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 0/6] Improve tag checking in fsck and with transfer.fsckobjects

[Junio C Hamano]

Thanks. I think this is ready for 'next' and then down to 'master'
for the next release.
--
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

(local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream

[Toralf Förster]

Today I run again into the CR/LF pain when I pulled from BOINC upstream and me 
wonders how I can repair the repository using git-2.1.0 at a 32bit Linux 
without cloning the full repository again (as I did it in the past). FWIW I did 
not changed anything locally, I just do pull regularly from upstreem to create 
a tar-ball of the current version for my own purpose:


tfoerste@n22 ~/devel/trinity $ cd ~/devel/boinc-v2; git pull
remote: Counting objects: 104, done.
remote: Compressing objects: 100% (52/52), done.
remote: Total 52 (delta 42), reused 0 (delta 0)
Unpacking objects: 100% (52/52), done.
From git://boinc.berkeley.edu/boinc-v2
   ce97e85..d2e5582  master - origin/master
   194f1dc..4a696b4  client_release/7/7.4 - origin/client_release/7/7.4
Updating ce97e85..d2e5582
error: Your local changes to the following files would be overwritten by merge:
html/languages/translations/hu.po
html/languages/translations/nl.po
locale/bg/BOINC-Web.po
locale/da/BOINC-Web.po
locale/el/BOINC-Web.po
locale/fr/BOINC-Web.po
locale/hr/BOINC-Web.po
locale/hu/BOINC-Project-Generic.po
locale/hu/BOINC-Web.po
locale/it_IT/BOINC-Project-Generic.po
locale/lv/BOINC-Web.po
locale/nl/BOINC-Project-Generic.po
locale/nl/BOINC-Web.po
locale/pl/BOINC-Web.po
locale/pt_BR/BOINC-Web.po
locale/ro/BOINC-Web.po
locale/sk/BOINC-Web.po
locale/zh_TW/BOINC-Web.po
Please, commit your changes or stash them before you can merge.
Aborting

tfoerste@n22 ~/devel/boinc-v2 $ git diff

tfoerste@n22 ~/devel/boinc-v2 $ git status
On branch master
Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded.
  (use git pull to update your local branch)
Changes not staged for commit:
  (use git add file... to update what will be committed)
  (use git checkout -- file... to discard changes in working directory)

modified:   html/languages/translations/hu.po
modified:   html/languages/translations/nl.po
modified:   locale/bg/BOINC-Web.po
modified:   locale/da/BOINC-Web.po
modified:   locale/el/BOINC-Web.po
modified:   locale/fr/BOINC-Web.po
modified:   locale/hr/BOINC-Web.po
modified:   locale/hu/BOINC-Project-Generic.po
modified:   locale/hu/BOINC-Web.po
modified:   locale/it_IT/BOINC-Project-Generic.po
modified:   locale/lv/BOINC-Web.po
modified:   locale/nl/BOINC-Project-Generic.po
modified:   locale/nl/BOINC-Web.po
modified:   locale/pl/BOINC-Web.po
modified:   locale/pt_BR/BOINC-Web.po
modified:   locale/ro/BOINC-Web.po
modified:   locale/sk/BOINC-Web.po
modified:   locale/zh_TW/BOINC-Web.po

no changes added to commit (use git add and/or git commit -a)


tfoerste@n22 ~/devel/boinc-v2 $ git branch 
* master

tfoerste@n22 ~/devel/boinc-v2 $ git stash
warning: CRLF will be replaced by LF in html/languages/translations/hu.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in html/languages/translations/nl.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/bg/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/da/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/el/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/fr/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/hr/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/hu/BOINC-Project-Generic.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/hu/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/it_IT/BOINC-Project-Generic.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/lv/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/nl/BOINC-Project-Generic.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/nl/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/pl/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/pt_BR/BOINC-Web.po.
The file 

Re: [PATCH] t9300: use cmp instead of test_cmp to compare binary files

[Thomas Braun]

Am 12.09.2014 um 19:58 schrieb Junio C Hamano:
 Johannes Sixt j...@kdbg.org writes:
 
 test_cmp is intended to produce diff output for human consumption. The
 input in one instance in t9300-fast-import.sh are binary files, however.
 Use cmp to compare the files.
 
 Thanks.
 

 This was noticed because on Windows we have a special implementation of
 test_cmp in pure bash code (to ignore differences due to intermittent CR
 in actual output), and bash runs into an infinite loop due to the binary
 nature of the input.

 Signed-off-by: Johannes Sixt j...@kdbg.org
 ---
  t/t9300-fast-import.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
 index 99f5161..4b13170 100755
 --- a/t/t9300-fast-import.sh
 +++ b/t/t9300-fast-import.sh
 @@ -2687,7 +2687,7 @@ test_expect_success 'R: verify created pack' '
  test_expect_success \
  'R: verify written objects' \
  'git --git-dir=R/.git cat-file blob big-file:big1 actual 
 - test_cmp expect actual 
 + cmp expect actual 
   a=$(git --git-dir=R/.git rev-parse big-file:big1) 
   b=$(git --git-dir=R/.git rev-parse big-file:big2) 
   test $a = $b'

May I suggest to use test_cmp_bin instead of plain cmp?
test_cmp_bin was introduced in
b93e6e36 (t5000, t5003: do not use test_cmp to compare binary files,
2014-06-04) and by default is plain cmp.


--
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: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream

[Rom Walton]

Try:
git checkout -f master
git pull origin

I committed fixes for that stuff this morning.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Toralf 
Förster
Sent: Friday, September 12, 2014 2:09 PM
To: git@vger.kernel.org
Cc: boinc_...@ssl.berkeley.edu
Subject: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the 
CR/LF changes made upstream

Today I run again into the CR/LF pain when I pulled from BOINC upstream and me 
wonders how I can repair the repository using git-2.1.0 at a 32bit Linux 
without cloning the full repository again (as I did it in the past). FWIW I did 
not changed anything locally, I just do pull regularly from upstreem to create 
a tar-ball of the current version for my own purpose:


tfoerste@n22 ~/devel/trinity $ cd ~/devel/boinc-v2; git pull
remote: Counting objects: 104, done.
remote: Compressing objects: 100% (52/52), done.
remote: Total 52 (delta 42), reused 0 (delta 0) Unpacking objects: 100% 
(52/52), done.
From git://boinc.berkeley.edu/boinc-v2
   ce97e85..d2e5582  master - origin/master
   194f1dc..4a696b4  client_release/7/7.4 - origin/client_release/7/7.4 
Updating ce97e85..d2e5582
error: Your local changes to the following files would be overwritten by merge:
html/languages/translations/hu.po
html/languages/translations/nl.po
locale/bg/BOINC-Web.po
locale/da/BOINC-Web.po
locale/el/BOINC-Web.po
locale/fr/BOINC-Web.po
locale/hr/BOINC-Web.po
locale/hu/BOINC-Project-Generic.po
locale/hu/BOINC-Web.po
locale/it_IT/BOINC-Project-Generic.po
locale/lv/BOINC-Web.po
locale/nl/BOINC-Project-Generic.po
locale/nl/BOINC-Web.po
locale/pl/BOINC-Web.po
locale/pt_BR/BOINC-Web.po
locale/ro/BOINC-Web.po
locale/sk/BOINC-Web.po
locale/zh_TW/BOINC-Web.po
Please, commit your changes or stash them before you can merge.
Aborting

tfoerste@n22 ~/devel/boinc-v2 $ git diff

tfoerste@n22 ~/devel/boinc-v2 $ git status On branch master Your branch is 
behind 'origin/master' by 7 commits, and can be fast-forwarded.
  (use git pull to update your local branch) Changes not staged for commit:
  (use git add file... to update what will be committed)
  (use git checkout -- file... to discard changes in working directory)

modified:   html/languages/translations/hu.po
modified:   html/languages/translations/nl.po
modified:   locale/bg/BOINC-Web.po
modified:   locale/da/BOINC-Web.po
modified:   locale/el/BOINC-Web.po
modified:   locale/fr/BOINC-Web.po
modified:   locale/hr/BOINC-Web.po
modified:   locale/hu/BOINC-Project-Generic.po
modified:   locale/hu/BOINC-Web.po
modified:   locale/it_IT/BOINC-Project-Generic.po
modified:   locale/lv/BOINC-Web.po
modified:   locale/nl/BOINC-Project-Generic.po
modified:   locale/nl/BOINC-Web.po
modified:   locale/pl/BOINC-Web.po
modified:   locale/pt_BR/BOINC-Web.po
modified:   locale/ro/BOINC-Web.po
modified:   locale/sk/BOINC-Web.po
modified:   locale/zh_TW/BOINC-Web.po

no changes added to commit (use git add and/or git commit -a)


tfoerste@n22 ~/devel/boinc-v2 $ git branch
* master

tfoerste@n22 ~/devel/boinc-v2 $ git stash
warning: CRLF will be replaced by LF in html/languages/translations/hu.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in html/languages/translations/nl.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/bg/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/da/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/el/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/fr/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/hr/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/hu/BOINC-Project-Generic.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/hu/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/it_IT/BOINC-Project-Generic.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/lv/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in 

Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream

[Toralf Förster]

On 09/12/2014 08:19 PM, Rom Walton wrote:
 Try:
 git checkout -f master
 git pull origin
 
 I committed fixes for that stuff this morning.

doesn't helped :

tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f master
Already on 'master'
Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded.
  (use git pull to update your local branch)

tfoerste@n22 ~/devel/boinc-v2 $ git pull origin
Updating ce97e85..d2e5582
error: Your local changes to the following files would be overwritten by merge:
html/languages/translations/hu.po
html/languages/translations/nl.po
locale/bg/BOINC-Web.po
locale/da/BOINC-Web.po
locale/el/BOINC-Web.po
locale/fr/BOINC-Web.po
locale/hr/BOINC-Web.po
locale/hu/BOINC-Project-Generic.po
locale/hu/BOINC-Web.po
locale/it_IT/BOINC-Project-Generic.po
locale/lv/BOINC-Web.po
locale/nl/BOINC-Project-Generic.po
locale/nl/BOINC-Web.po
locale/pl/BOINC-Web.po
locale/pt_BR/BOINC-Web.po
locale/ro/BOINC-Web.po
locale/sk/BOINC-Web.po
locale/zh_TW/BOINC-Web.po
Please, commit your changes or stash them before you can merge.
Aborting

-- 
Toralf
pgp key: 0076 E94E

--
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: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream

[Rom Walton]

Crud...

Well, personally, I would delete the locale directory and the two translation 
files in html.

Do the 'git pull', and then switch between master and some other branch.

like:
git checkout -f client_release/7/7.4
git checkout -f master

It is round about, but it should get the job done.

- Rom

-Original Message-
From: Toralf Förster [mailto:toralf.foers...@gmx.de] 
Sent: Friday, September 12, 2014 2:32 PM
To: Rom Walton; git@vger.kernel.org
Cc: boinc_...@ssl.berkeley.edu
Subject: Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on 
the CR/LF changes made upstream

On 09/12/2014 08:19 PM, Rom Walton wrote:
 Try:
 git checkout -f master
 git pull origin
 
 I committed fixes for that stuff this morning.

doesn't helped :

tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f master Already on 'master'
Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded.
  (use git pull to update your local branch)

tfoerste@n22 ~/devel/boinc-v2 $ git pull origin Updating ce97e85..d2e5582
error: Your local changes to the following files would be overwritten by merge:
html/languages/translations/hu.po
html/languages/translations/nl.po
locale/bg/BOINC-Web.po
locale/da/BOINC-Web.po
locale/el/BOINC-Web.po
locale/fr/BOINC-Web.po
locale/hr/BOINC-Web.po
locale/hu/BOINC-Project-Generic.po
locale/hu/BOINC-Web.po
locale/it_IT/BOINC-Project-Generic.po
locale/lv/BOINC-Web.po
locale/nl/BOINC-Project-Generic.po
locale/nl/BOINC-Web.po
locale/pl/BOINC-Web.po
locale/pt_BR/BOINC-Web.po
locale/ro/BOINC-Web.po
locale/sk/BOINC-Web.po
locale/zh_TW/BOINC-Web.po
Please, commit your changes or stash them before you can merge.
Aborting

--
Toralf
pgp key: 0076 E94E

N�r��yb�X��ǧv�^�)޺{.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Jonathan Nieder jrnie...@gmail.com writes:

 Junio C Hamano wrote:
 Jonathan Nieder jrnie...@gmail.com writes:

 These patches are also available from the git repository at

   git://repo.or.cz/git/jrn.git tags/rs/ref-transaction

 The tag fetched and built as-is seems to break 5514 among other
 things (git remote rm segfaults).

 Yeah, I noticed that right after sending the series out. :/

 The patch below fixes it[1].

Is this meant to replace anything, or is it Oops, the previous ones
are broken, and this is to patch it up on top?

 -- 8 --
 From: Ronnie Sahlberg sahlb...@google.com
 Date: Thu, 11 Sep 2014 08:42:57 -0700
 Subject: remote rm/prune: print a message when writing packed-refs fails

 Until v2.1.0-rc0~22^2~11 (refs.c: add an err argument to
 repack_without_refs, 2014-06-20), repack_without_refs forgot to
 provide an error message when commit_packed_refs fails.  Even today,
 it only provides a message for callers that pass a non-NULL err
 parameter.  Internal callers in refs.c pass non-NULL err but
 git remote does not.

 That means that git remote rm and git remote prune can fail
 without printing a message about why.  Fix them by passing in a
 non-NULL err parameter and printing the returned message.

 This is the last caller to a ref handling function passing err ==
 NULL.  A later patch can drop support for err == NULL, avoiding such
 problems in the future.

 Change-Id: Ifb8a726ef03d0aa282a25a102313064d2e8ec283
 Signed-off-by: Ronnie Sahlberg sahlb...@google.com
 Signed-off-by: Jonathan Nieder jrnie...@gmail.com
 ---
 [1] https://code-review.googlesource.com/1110
 https://code-review.googlesource.com/1060

  builtin/remote.c | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)

 diff --git a/builtin/remote.c b/builtin/remote.c
 index 6eaeee7..ef1ffc3 100644
 --- a/builtin/remote.c
 +++ b/builtin/remote.c
 @@ -750,13 +750,16 @@ static int mv(int argc, const char **argv)
  
  static int remove_branches(struct string_list *branches)
  {
 + struct strbuf err = STRBUF_INIT;
   const char **branch_names;
   int i, result = 0;
  
   branch_names = xmalloc(branches-nr * sizeof(*branch_names));
   for (i = 0; i  branches-nr; i++)
   branch_names[i] = branches-items[i].string;
 - result |= repack_without_refs(branch_names, branches-nr, NULL);
 + if (repack_without_refs(branch_names, branches-nr, err))
 + result |= error(%s, err.buf);
 + strbuf_release(err);
   free(branch_names);
  
   for (i = 0; i  branches-nr; i++) {
 @@ -1333,9 +1336,13 @@ static int prune_remote(const char *remote, int 
 dry_run)
   delete_refs = xmalloc(states.stale.nr * sizeof(*delete_refs));
   for (i = 0; i  states.stale.nr; i++)
   delete_refs[i] = states.stale.items[i].util;
 - if (!dry_run)
 - result |= repack_without_refs(delete_refs,
 -   states.stale.nr, NULL);
 + if (!dry_run) {
 + struct strbuf err = STRBUF_INIT;
 + if (repack_without_refs(delete_refs, states.stale.nr,
 + err))
 + result |= error(%s, err.buf);
 + strbuf_release(err);
 + }
   free(delete_refs);
   }
--
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: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream

[Toralf Förster]

On 09/12/2014 08:55 PM, Rom Walton wrote:
 Crud...
 
 Well, personally, I would delete the locale directory and the two translation 
 files in html.
 
 Do the 'git pull', and then switch between master and some other branch.
 
 like:
 git checkout -f client_release/7/7.4
 git checkout -f master
 
 It is round about, but it should get the job done.

Re-cloning seems to be the only way, b/c :

tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f client_release/7/7.4
Branch client_release/7/7.4 set up to track remote branch client_release/7/7.4 
from origin.
Switched to a new branch 'client_release/7/7.4'

tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f master
Checking out files: 100% (234/234), done.
Switched to branch 'master'
Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded.
  (use git pull to update your local branch)

tfoerste@n22 ~/devel/boinc-v2 $ git pull
Updating ce97e85..d2e5582
error: Your local changes to the following files would be overwritten by merge:
...
same picture as before

-- 
Toralf
pgp key: 0076 E94E

--
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] stash: prefer --quiet over shell redirection

[Junio C Hamano]

David Aguilar dav...@gmail.com writes:

 Use `git rev-parse --verify --quiet` instead of redirecting
 stderr to /dev/null.

 Signed-off-by: David Aguilar dav...@gmail.com
 ---

Has this patch ever been tested?  t3903 seems to break with this at
least for me.

  git-stash.sh | 13 +++--
  1 file changed, 7 insertions(+), 6 deletions(-)

 diff --git a/git-stash.sh b/git-stash.sh
 index bcc757b..2ff8b94 100755
 --- a/git-stash.sh
 +++ b/git-stash.sh
 @@ -50,7 +50,7 @@ clear_stash () {
   then
   die $(gettext git stash clear with parameters is 
 unimplemented)
   fi
 - if current=$(git rev-parse --verify $ref_stash 2/dev/null)
 + if current=$(git rev-parse --verify --quiet $ref_stash)
   then
   git update-ref -d $ref_stash $current
   fi
 @@ -292,7 +292,7 @@ save_stash () {
  }
  
  have_stash () {
 - git rev-parse --verify $ref_stash /dev/null 21
 + git rev-parse --verify --quiet $ref_stash /dev/null
  }
  
  list_stash () {
 @@ -392,12 +392,12 @@ parse_flags_and_rev()
   ;;
   esac
  
 - REV=$(git rev-parse --quiet --symbolic --verify $1 2/dev/null) || {
 + REV=$(git rev-parse --symbolic --verify --quiet $1) || {
   reference=$1
   die $(eval_gettext \$reference is not valid reference)
   }
  
 - i_commit=$(git rev-parse --quiet --verify $REV^2 2/dev/null) 
 + i_commit=$(git rev-parse --verify --quiet $REV^2) 
   set -- $(git rev-parse $REV $REV^1 $REV: $REV^1: $REV^2: 
 2/dev/null) 
   s=$1 
   w_commit=$1 
 @@ -409,7 +409,7 @@ parse_flags_and_rev()
   test $ref_stash = $(git rev-parse --symbolic-full-name ${REV%@*}) 
 
   IS_STASH_REF=t
  
 - u_commit=$(git rev-parse --quiet --verify $REV^3 2/dev/null) 
 + u_commit=$(git rev-parse --verify --quiet $REV^3) 
   u_tree=$(git rev-parse $REV^3: 2/dev/null)
  }
  
 @@ -531,7 +531,8 @@ drop_stash () {
   die $(eval_gettext \${REV}: Could not drop stash entry)
  
   # clear_stash if we just dropped the last stash entry
 - git rev-parse --verify $ref_stash@{0} /dev/null 21 || clear_stash
 + git rev-parse --verify --quiet $ref_stash@{0} /dev/null ||
 + clear_stash
  }
  
  apply_to_branch () {
--
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 23/32] prune: strategies for linked checkouts

[Marc Branchaud]

On 14-09-11 11:06 PM, Eric Sunshine wrote:
 On Thu, Sep 11, 2014 at 11:36 AM, Marc Branchaud marcn...@xiplink.com wrote:
 On 14-09-10 06:41 PM, Nguyễn Thái Ngọc Duy wrote:
 (alias R=$GIT_COMMON_DIR/worktrees/id)

  - linked checkouts are supposed to keep its location in $R/gitdir up
to date. The use case is auto fixup after a manual checkout move.

  - linked checkouts are supposed to update mtime of $R/gitdir. If
$R/gitdir's mtime is older than a limit, and it points to nowhere,
worktrees/id is to be pruned.

  - If $R/locked exists, worktrees/id is not supposed to be pruned. If
$R/locked exists and $R/gitdir's mtime is older than a really long
limit, warn about old unused repo.

  - git checkout --to is supposed to make a hard link named $R/link
pointing to the .git file on supported file systems to help detect
the user manually deleting the checkout. If $R/link exists and its
link count is greated than 1, the repo is kept.

 Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
 ---
  Documentation/git-checkout.txt | 18 ++
  Documentation/git-prune.txt|  3 +
  Documentation/gitrepository-layout.txt | 19 ++
  builtin/checkout.c | 19 +-
  builtin/prune.c| 95 
 ++
  setup.c| 13 
  t/t2026-prune-linked-checkouts.sh (new +x) | 84 ++
  7 files changed, 249 insertions(+), 2 deletions(-)
  create mode 100755 t/t2026-prune-linked-checkouts.sh

 diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
 index bd0fc1d..a29748e 100644
 --- a/Documentation/git-checkout.txt
 +++ b/Documentation/git-checkout.txt
 @@ -431,6 +431,24 @@ thumb is do not make any assumption about whether a 
 path belongs to
  $GIT_DIR or $GIT_COMMON_DIR when you need to directly access something
  inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path.

 +When you are done, simply deleting the linked working directory would
 +suffice. $GIT_DIR/worktrees can be cleaned up using `git prune
 +--worktrees`.

 This needs a tweak or two so that it follows more naturally from the previous
 paragraph.  How about:

 When you are done with a linked working tree you can simply delete
 it.  You can clean up any stale $GIT_DIR/worktrees entries with
 `git prune --worktrees`.
 
 Thanks for these rewrites; I was going to provide similar suggestions.
 
 One minor addition for clarification would be to mention that the 'git
 prune --worktrees' invocation applies to the main worktree:
 
 When you are done with a linked working tree, you can simply delete
 it. You can clean up any stale $GIT_DIR/worktrees entries via
 `git prune --worktrees` in the main worktree.
 
 Then in commit 28, when you add worktrees pruning to gc, you should change
 this paragraph again:

 When you are done with a linked working tree you can simply delete
 it.  The working tree's entry in the repository's $GIT_DIR/worktrees
 directory will eventually be removed automatically (see
 `gc.pruneworktreesexpire` in linkgit::git-config[1]), or you can run
 `git prune --worktrees` to clean up any stale entries in
 $GIT_DIR/worktrees.
 
 Ditto about qualifying 'git prune --worktrees' with in the main work tree.
 
 +After you move a linked working directory to another file system, or
 +on a file system that does not support hard link, execute any git
 +command (e.g. `git status`) in the new working directory so that it
 +could update its location in $GIT_DIR/worktrees and not be
 +accidentally pruned.

 It took me a couple of seconds to parse that.  How about:

 If you move a linked working directory to another file system, or
 within a file system that does not support hard links, you need to
 run at least one git command inside the moved linked working
 
 I trip over moved linked every time I read it. I think there's
 sufficient context in the 'if' clause leading to this that moved can
 be dropped.

Fine by me, as are your other suggestions.

M.


 directory (e.g. `git status`) in order to update its entry in
 $GIT_DIR/worktrees so that it does not get automatically removed.

 +To stop `git prune --worktrees` from deleting a specific working
 +directory (e.g. because it's on a portable device), you could add the
 +file 'locked' to $GIT_DIR/worktrees. For example, if `.git` file of
 +the new working directory points to `/path/main/worktrees/test-next`,
 +the full path of the 'locked' file would be
 +`/path/main/worktrees/test-next/locked`. See
 +linkgit:gitrepository-layout[5] for details.

 Sorry, I can't help rewriting this one too:

 To prevent `git prune --worktrees` from deleting a
 $GIT_DIR/worktrees entry (which can be useful in some situations,
 such as when the entry's 

RE: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream

[Rom Walton]

I found this:
http://stackoverflow.com/questions/17223527/how-do-i-force-git-to-checkout-the-master-branch-and-remove-carriage-returns-aft

That might help in the future.

- Rom

-Original Message-
From: Toralf Förster [mailto:toralf.foers...@gmx.de] 
Sent: Friday, September 12, 2014 3:04 PM
To: Rom Walton; git@vger.kernel.org
Cc: boinc_...@ssl.berkeley.edu
Subject: Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on 
the CR/LF changes made upstream

On 09/12/2014 08:55 PM, Rom Walton wrote:
 Crud...
 
 Well, personally, I would delete the locale directory and the two translation 
 files in html.
 
 Do the 'git pull', and then switch between master and some other branch.
 
 like:
 git checkout -f client_release/7/7.4
 git checkout -f master
 
 It is round about, but it should get the job done.

Re-cloning seems to be the only way, b/c :

tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f client_release/7/7.4 Branch 
client_release/7/7.4 set up to track remote branch client_release/7/7.4 from 
origin.
Switched to a new branch 'client_release/7/7.4'

tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f master Checking out files: 100% 
(234/234), done.
Switched to branch 'master'
Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded.
  (use git pull to update your local branch)

tfoerste@n22 ~/devel/boinc-v2 $ git pull Updating ce97e85..d2e5582
error: Your local changes to the following files would be overwritten by merge:
...
same picture as before

--
Toralf
pgp key: 0076 E94E

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Jonathan Nieder]

Junio C Hamano wrote:
 Jonathan Nieder jrnie...@gmail.com writes:
  Junio C Hamano wrote:

 The tag fetched and built as-is seems to break 5514 among other
 things (git remote rm segfaults).

 Yeah, I noticed that right after sending the series out. :/

 The patch below fixes it[1].

 Is this meant to replace anything, or is it Oops, the previous ones
 are broken, and this is to patch it up on top?

It's Oops, the next one (refs.c: do not permit err == NULL) is broken,
and this is to patch it up in advance. :)

But it should apply on top, too.

There were a few other minor changes, and I think with them the series
should be ready for next.  My send and hope that more reviewers
appear strategy didn't really work, so I'll send a reroll of the
series as-is in an hour or so.

Here's an interdiff as a preview.

diff --git a/builtin/branch.c b/builtin/branch.c
index 5d5bc56..4bf931e 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -238,9 +238,7 @@ static int delete_branches(int argc, const char **argv, int 
force, int kinds,
RESOLVE_REF_READING
| RESOLVE_REF_NODEREF
| RESOLVE_REF_ALLOW_BAD_NAME);
-   if (!target ||
-   (!(flags  (REF_ISSYMREF|REF_ISBROKEN)) 
-is_null_sha1(sha1))) {
+   if (!target) {
error(remote_branch
  ? _(remote branch '%s' not found.)
  : _(branch '%s' not found.), bname.buf);
@@ -268,8 +266,8 @@ static int delete_branches(int argc, const char **argv, int 
force, int kinds,
   ? _(Deleted remote branch %s (was %s).\n)
   : _(Deleted branch %s (was %s).\n),
   bname.buf,
-  (flags  REF_ISSYMREF)
-  ? target
+  (flags  REF_ISBROKEN) ? broken
+  : (flags  REF_ISSYMREF) ? target
   : find_unique_abbrev(sha1, DEFAULT_ABBREV));
}
delete_branch_config(bname.buf);
diff --git a/builtin/remote.c b/builtin/remote.c
index 6eaeee7..ef1ffc3 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -750,13 +750,16 @@ static int mv(int argc, const char **argv)
 
 static int remove_branches(struct string_list *branches)
 {
+   struct strbuf err = STRBUF_INIT;
const char **branch_names;
int i, result = 0;
 
branch_names = xmalloc(branches-nr * sizeof(*branch_names));
for (i = 0; i  branches-nr; i++)
branch_names[i] = branches-items[i].string;
-   result |= repack_without_refs(branch_names, branches-nr, NULL);
+   if (repack_without_refs(branch_names, branches-nr, err))
+   result |= error(%s, err.buf);
+   strbuf_release(err);
free(branch_names);
 
for (i = 0; i  branches-nr; i++) {
@@ -1333,9 +1336,13 @@ static int prune_remote(const char *remote, int dry_run)
delete_refs = xmalloc(states.stale.nr * sizeof(*delete_refs));
for (i = 0; i  states.stale.nr; i++)
delete_refs[i] = states.stale.items[i].util;
-   if (!dry_run)
-   result |= repack_without_refs(delete_refs,
- states.stale.nr, NULL);
+   if (!dry_run) {
+   struct strbuf err = STRBUF_INIT;
+   if (repack_without_refs(delete_refs, states.stale.nr,
+   err))
+   result |= error(%s, err.buf);
+   strbuf_release(err);
+   }
free(delete_refs);
}
 
--
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: Issue with 'git diff' and non ascii characters

[Torsten Bögershausen]

On 2014-09-12 08.53, Giulio Cesare Solaroli wrote:
 Hello,
 
 I have spotted a problem using 'git diff' when non ascii characters are 
 involved.
 Not sure if the problem is due to the name of the file, or its content.
 
 Cheers,
 
 Giulio Cesare
 
 Steps to reproduce the problem:
 
 $ sw_vers
 ProductName:  Mac OS X
 ProductVersion:   10.9.4
 BuildVersion: 13E28
 $ git --version
 git version 1.8.5.2 (Apple Git-48)
 $ mkdir test
 $ cd test
 $ echo prova  tèst.md
 $ git init
 Initialized empty Git repository in /private/tmp/test/.git/
 $ git add *
 $ git commit -m first commit
 [master (root-commit) ebbe2a3] first commit
  1 file changed, 1 insertion(+)
  create mode 100644 t\303\250st.md
 $ echo provà  tèst.md 
 $ git status
 On branch master
 Changes not staged for commit:
   (use git add file... to update what will be committed)
   (use git checkout -- file... to discard changes in working directory)
 
   modified:   t\303\250st.md
 
 no changes added to commit (use git add and/or git commit -a)
 $ git diff tèst.md 
 $ 
The problem is not the contents of the file, but the file name.

The following should help:

git config core.quotepath false

--
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] t9300: use test_cmp_bin instead of test_cmp to compare binary files

[Johannes Sixt]

test_cmp is intended to produce diff output for human consumption. The
input in one instance in t9300-fast-import.sh are binary files, however.
Use test_cmp_bin to compare the files.

This was noticed because on Windows we have a special implementation of
test_cmp in pure bash code (to ignore differences due to intermittent CR
in actual output), and bash runs into an infinite loop due to the binary
nature of the input.

Signed-off-by: Johannes Sixt j...@kdbg.org
---
Am 12.09.2014 um 20:14 schrieb Thomas Braun:
 May I suggest to use test_cmp_bin instead of plain cmp?

Of course! I did remember that there was talk about it, but missed
that we actually implemented it. Sorry.

 t/t9300-fast-import.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 99f5161..72845f6 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -2687,7 +2687,7 @@ test_expect_success 'R: verify created pack' '
 test_expect_success \
'R: verify written objects' \
'git --git-dir=R/.git cat-file blob big-file:big1 actual 
-test_cmp expect actual 
+test_cmp_bin expect actual 
 a=$(git --git-dir=R/.git rev-parse big-file:big1) 
 b=$(git --git-dir=R/.git rev-parse big-file:big2) 
 test $a = $b'
-- 
2.0.0.12.gbcf935e

--
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 v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Jonathan Nieder jrnie...@gmail.com writes:

 It's Oops, the next one (refs.c: do not permit err == NULL) is broken,
 and this is to patch it up in advance. :)

 But it should apply on top, too.

I think in advance makes sense for this one, too.

 There were a few other minor changes, and I think with them the series
 should be ready for next.  My send and hope that more reviewers
 appear strategy didn't really work,...

You sent them just a few days ago.  Expecting anybody to have a
solid time to sit thru a 19-patch series inside that timeframe is
not so realistic.

 so I'll send a reroll of the series as-is in an hour or so.

OK.  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 v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Junio C Hamano gits...@pobox.com writes:

 Jonathan Nieder jrnie...@gmail.com writes:

 It's Oops, the next one (refs.c: do not permit err == NULL) is broken,
 and this is to patch it up in advance. :)

 But it should apply on top, too.

 I think in advance makes sense for this one, too.

 There were a few other minor changes, and I think with them the series
 should be ready for next.  My send and hope that more reviewers
 appear strategy didn't really work,...

 You sent them just a few days ago.  Expecting anybody to have a
 solid time to sit thru a 19-patch series inside that timeframe is
 not so realistic.

 so I'll send a reroll of the series as-is in an hour or so.

 OK.  Thanks.

I do not think I have enough time to pick a reroll up to redo the
day's integration, so please take time to make it perfect.

I noticed that with this series merged to the version I use daily,
detaching HEAD (i.e. git checkout HEAD^0) breaks my HEAD reflog,
which made me redo the integration ejecting the series out of 'pu'.

Not happy, as my workflow relies fairly heavily on detached HEAD
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

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Michael Haggerty]

On 09/12/2014 09:56 PM, Junio C Hamano wrote:
 Jonathan Nieder jrnie...@gmail.com writes:
 [...]
 There were a few other minor changes, and I think with them the series
 should be ready for next.  My send and hope that more reviewers
 appear strategy didn't really work,...
 
 You sent them just a few days ago.  Expecting anybody to have a
 solid time to sit thru a 19-patch series inside that timeframe is
 not so realistic.

It's hard to tell from my glacial (tectonic?) pace, but I really do plan
to work through all of Ronnie's ref-related patches. Of course it's up
to you whether to wait for me. I really hope to get through the third
series by the end of next week.

 so I'll send a reroll of the series as-is in an hour or so.

Jonathan: Is a current version of this patch series set up for review in
Gerrit?

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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

[RFC] allowing hooks to ignore input?

[Junio C Hamano]

The pre-receive and post-receive hooks were designed to be an
improvement over old style update and post-update hooks that used to
take the update information on the command line and were limited by
the command line length limit.  They take the same information from
their standard input.  It has been mandatory for these new style
hooks to consume the update information fully from the standard
input stream.  Otherwise, they would risk killing the receive-pack
process via SIGPIPE.

This is easy, and it has already been done by existing hooks that
are written correctly, to work around, if a hook does not want to
look at all the information, by sending its standard input to
/dev/null (perhaps a niche use of hook might need to know only the
fact that a push was made, without having to know what objects have
been pushed to update which refs).

However, because there is no good way to consistently fail hooks
that do not consume the input fully, it can lead to a hard to
diagnose once in a blue moon phantom failure.

I wonder if this you must consume the input fully, which is a
mandate that is not enforced strictly, is not helping us to catch
mistakes in hooks more than it is hurting us.  Perhaps we can do
something like the attached patch to make it optional for them to
read the input we feed?

I dunno.

 builtin/receive-pack.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 30560a7..9d9d16d 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -17,6 +17,7 @@
 #include version.h
 #include tag.h
 #include gpg-interface.h
+#include sigchain.h
 
 static const char receive_pack_usage[] = git receive-pack git-dir;
 
@@ -500,6 +501,8 @@ static int run_and_feed_hook(const char *hook_name, feed_fn 
feed, void *feed_sta
return code;
}
 
+   sigchain_push(SIGPIPE, SIG_IGN);
+
while (1) {
const char *buf;
size_t n;
@@ -511,6 +514,9 @@ static int run_and_feed_hook(const char *hook_name, feed_fn 
feed, void *feed_sta
close(proc.in);
if (use_sideband)
finish_async(muxer);
+
+   sigchain_pop(SIGPIPE);
+
return finish_command(proc);
 }
 
--
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 v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Jonathan Nieder]

Michael Haggerty wrote:
 Jonathan Nieder jrnie...@gmail.com writes:

 so I'll send a reroll of the series as-is in an hour or so.

 Jonathan: Is a current version of this patch series set up for review in
 Gerrit?

Yes.
(https://code-review.googlesource.com/#/q/project:git+topic:ref-transaction)

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