author | Elijah Newren <newren@gmail.com> | |
Sat, 13 Aug 2011 02:23:51 +0000 (20:23 -0600) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Sun, 14 Aug 2011 21:27:48 +0000 (14:27 -0700) | ||
commit | f701aae0774f4517b46dd866812c269c78f1e198 | |
tree | 4f180d1b3ca79803241055e843909a2300f556f6 | tree | snapshot |
parent | 6d63070cacf88cd03b4bc73fd64fea046accd450 | commit | diff |
merge-recursive: Don't re-sort a list whose order we depend upon
In record_df_conflict_files() we would resort the entries list using
df_name_compare to get a convenient ordering. Unfortunately, this broke
assumptions of the get_renames() code (via string_list_lookup() calls)
which needed the list to be in the standard ordering. When those lookups
would fail, duplicate stage_data entries could be inserted, causing the
process_renames and process_entry code to fail (in particular, a path that
that process_renames had marked as processed would still be processed
anyway in process_entry due to the duplicate entry).
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In record_df_conflict_files() we would resort the entries list using
df_name_compare to get a convenient ordering. Unfortunately, this broke
assumptions of the get_renames() code (via string_list_lookup() calls)
which needed the list to be in the standard ordering. When those lookups
would fail, duplicate stage_data entries could be inserted, causing the
process_renames and process_entry code to fail (in particular, a path that
that process_renames had marked as processed would still be processed
anyway in process_entry due to the duplicate entry).
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive.c | diff | blob | history |