kernel/git - git - PowerEL Git System

42903 Commits

6 Branches

36 Tags

131 MiB

Tree: a1bc3dd464

Commit Graph

Author	SHA1	Message	Date
Jeff King	e6821d09e4	t: fix some trivial cases of ignored exit codes in loops These are all cases where we do a setup step of the form: for i in $foo; do set_up $i \|\| break done && more_setup would not notice a failure in set_up (because break always returns a 0 exit code). These are just setup steps that we do not expect to fail, but it does not hurt to be defensive. Most can be fixed by converting the "break" to a "return 1" (since we eval our tests inside a function for just this purpose). A few of the loops are inside subshells, so we can use just "exit 1" to break out of the subshell. And a few can actually be made shorter by just unrolling the loop. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Dave Olszewski	bf74106a5b	merge-recursive: never leave index unmerged while recursing When you are trying to come up with the final result (i.e. depth=0), you want to record how the conflict arose by registering the state of the common ancestor, your branch and the other branch in the index, hence you want to do update_stages(). When you are merging with positive depth, that is because of a criss-cross merge situation. In such a case, you would need to record the tentative result, with conflict markers and all, as if the merge went cleanly, even if there are conflicts, in order to write it out as a tree object later to be used as a common ancestor tree. update_file() calls update_file_flags() with update_cache=1 to signal that the result needs to be written to the index at stage #0 (i.e. merged), and the code should not clobber the index further by calling update_stages(). The codepath to deal with rename/delete conflict in a recursive merge however left the index unmerged. Signed-off-by: Dave Olszewski <cxreg@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago

Author

SHA1

Message

Date

Jeff King

e6821d09e4

t: fix some trivial cases of ignored exit codes in loops

These are all cases where we do a setup step of the form:

  for i in $foo; do
	  set_up $i || break
  done &&
  more_setup

would not notice a failure in set_up (because break always
returns a 0 exit code). These are just setup steps that we
do not expect to fail, but it does not hurt to be defensive.

Most can be fixed by converting the "break" to a "return 1"
(since we eval our tests inside a function for just this
purpose). A few of the loops are inside subshells, so we can
use just "exit 1" to break out of the subshell. And a few
can actually be made shorter by just unrolling the loop.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

10 years ago

Dave Olszewski

bf74106a5b

merge-recursive: never leave index unmerged while recursing

When you are trying to come up with the final result (i.e. depth=0), you
want to record how the conflict arose by registering the state of the
common ancestor, your branch and the other branch in the index, hence you
want to do update_stages().

When you are merging with positive depth, that is because of a criss-cross
merge situation.  In such a case, you would need to record the tentative
result, with conflict markers and all, as if the merge went cleanly, even
if there are conflicts, in order to write it out as a tree object later to
be used as a common ancestor tree.

update_file() calls update_file_flags() with update_cache=1 to signal that
the result needs to be written to the index at stage #0 (i.e. merged), and
the code should not clobber the index further by calling update_stages().

The codepath to deal with rename/delete conflict in a recursive merge
however left the index unmerged.

Signed-off-by: Dave Olszewski <cxreg@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

16 years ago

2 Commits (a1bc3dd46433c6e7e6f1ca5f3bd5429858a60078)