undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

fast-import: clarify "inline" logic in file_change_m

Browse Source 
When we read a fast-import line like:

  M 100644 :1 foo.c

we point the local object_entry variable "oe" to the object
named by the mark ":1". When the input uses the "inline"
construct, however, we do not have such an object_entry.

The current code is careful not to access "oe" in the inline
case, but we can make the assumption even more obvious (and
catch violations of it) by setting oe to NULL and adding a
comment. As a bonus, this also squelches an over-zealous gcc
-Wuninitialized warning, which means we can drop the "oe =
oe" initialization hack.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Jeff King 2013-03-21 11:44:39 -04:00 committed by Junio C Hamano
parent 25043d8aea
commit 3aa99df802
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
fast-import.c
View File

@ -2265,7 +2265,7 @@ static void file_change_m(struct branch *b)
const char *p = command_buf.buf + 2;
static struct strbuf uq = STRBUF_INIT;
const char *endp;
struct object_entry *oe = oe;
struct object_entry *oe;
unsigned char sha1[20];
uint16_t mode, inline_data = 0;
@ -2292,6 +2292,7 @@ static void file_change_m(struct branch *b)
hashcpy(sha1, oe->idx.sha1);
} else if (!prefixcmp(p, "inline ")) {
inline_data = 1;
oe = NULL; /* not used with inline_data, but makes gcc happy */
p += strlen("inline"); /* advance to space */
} else {
if (get_sha1_hex(p, sha1))