user/sven/git.git/object.c, branch v1.7.7.4

read_sha1_file(): get rid of read_sha1_file_repl() madness

2011-05-15T22:23:33Z

Most callers want to silently get a replacement object, and they do not care what the real name of the replacement object is. Worse yet, no sane interface to return the underlying object without replacement is provided. Remove the function and make only the few callers that want the name of the replacement object find it themselves. Signed-off-by: Junio C Hamano

Merge branch 'maint'

2010-09-06T07:12:04Z

* maint: tag.c: whitespace breakages fix Fix whitespace issue in object.c t5505: add missing &&

Merge branch 'xx/trivial' into maint

2010-09-06T07:11:59Z

* xx/trivial: tag.c: whitespace breakages fix Fix whitespace issue in object.c t5505: add missing &&

Fix whitespace issue in object.c

2010-09-06T05:12:29Z

Change some expanded tabs (spaces) to tabs in object.c. Signed-off-by: Jared Hance Signed-off-by: Junio C Hamano

Merge branch 'nd/maint-fix-replace'

2010-09-04T05:23:13Z

* nd/maint-fix-replace: parse_object: pass on the original sha1, not the replaced one

parse_object: pass on the original sha1, not the replaced one

2010-09-04T05:13:08Z

Commit 0e87c36 (object: call "check_sha1_signature" with the replacement sha1) changed the first argument passed to parse_object_buffer() from "sha1" to "repl". With that change, the returned obj pointer has the replacement SHA1 in obj->sha1, not the original one. But when using lookup_commit() and then parse_commit() on a commit, we get an object pointer with the original sha1, but the commit content comes from the replacement commit. So the result we get from using parse_object() is different from the we get from using lookup_commit() followed by parse_commit(). It looks much simpler and safer to fix this inconsistency by passing "sha1" to parse_object_bufer() instead of "repl". The commit comment should be used to tell the the replacement commit is replacing another commit and why. So it should be easy to see that we have a replacement commit instead of an original one. And it is not a problem if the content of the commit is not consistent with the sha1 as cat-file piped to hash-object can be used to see the difference. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

fix "bundle --stdin" segfault

2010-04-20T05:16:35Z

When passed an empty list, objects_array_remove_duplicates() corrupts it by changing the number of entries from 0 to 1. The problem lies in the condition of its main loop: for (ref = 0; ref < array->nr - 1; ref++) { The loop body manipulates the supplied object array. In the case of an empty array, it should not be doing anything at all. But array->nr is an unsigned quantity, so the code enters the loop, in particular increasing array->nr. Fix this by comparing (ref + 1 < array->nr) instead. This bug can be triggered by git bundle --stdin: $ echo HEAD | git bundle create some.bundle --stdin’ Segmentation fault (core dumped) The list of commits to bundle appears to be empty because of another bug: by the time the revision-walking machinery gets to look at it, standard input has already been consumed by rev-list, so this function gets an empty list of revisions. After this patch, git bundle --stdin still does not work; it just doesn’t segfault any more. Reported-by: Joey Hess Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

object.c: remove unused functions

2010-01-18T06:49:36Z

object_list_append() and object_list_length}() are not used anywhere. Signed-off-by: Junio C Hamano

object: call "check_sha1_signature" with the replacement sha1

2009-06-01T00:02:59Z

Otherwise we get a "sha1 mismatch" error for replaced objects. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

Unify signedness in hashing calls

2009-05-20T07:02:24Z

Our hash_obj and hashtable_index calls and functions were doing a lot of funny things with signedness. Unify all of it to 'unsigned int'. Signed-off-by: Dan McGee Signed-off-by: Junio C Hamano