| commit | 3aa99df802020f73981d1169c05375d5e2b49cc9 | |
| author | Jeff King <peff@peff.net> | |
| Thu, 21 Mar 2013 15:44:39 +0000 (21 11:44 -0400) | ||
| committer | Junio C Hamano <gitster@pobox.com> | |
| Thu, 21 Mar 2013 21:06:49 +0000 (21 14:06 -0700) | ||
| tree | 33bfaea35a4f076c337143d1b42406349d9831bf | treesnapshot (tar.gz zip) |
| parent | 25043d8aea7859497c12cb035e6688f76e32ac13 | commitdiff |
fast-import: clarify "inline" logic in file_change_m
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>
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>
| fast-import.c | diffblobblamehistory |