Граф коммитов

12 Коммитов

Автор SHA1 Сообщение Дата
Elijah Newren ad3762042a read-cache: fix directory/file conflict handling in read_index_unmerged()
read_index_unmerged() has two intended purposes:
  * return 1 if there are any unmerged entries, 0 otherwise
  * drops any higher-stage entries down to stage #0

There are several callers of read_index_unmerged() that check the return
value to see if it is non-zero, all of which then die() if that condition
is met.  For these callers, dropping higher-stage entries down to stage #0
is a waste of resources, and returning immediately on first unmerged entry
would be better.  But it's probably only a very minor difference and isn't
the focus of this series.

The remaining callers ignore the return value and call this function for
the side effect of dropping higher-stage entries down to stage #0.  As
mentioned in commit e11d7b5969 ("'reset --merge': fix unmerged case",
2009-12-31),

    The _only_ reason we want to keep a previously unmerged entry in the
    index at stage #0 is so that we don't forget the fact that we have
    corresponding file in the work tree in order to be able to remove it
    when the tree we are resetting to does not have the path.

In fact, prior to commit d1a43f2aa4 ("reset --hard/read-tree --reset -u:
remove unmerged new paths", 2008-10-15), read_index_unmerged() did just
remove unmerged entries from the cache immediately but that had the
unwanted effect of leaving around new untracked files in the tree from
aborted merges.

So, that's the intended purpose of this function.  The problem is that
when directory/files conflicts are present, trying to add the file to the
index at stage 0 fails (because there is still a directory in the way),
and the function returns early with a -1 return code to signify the error.
As noted above, none of the callers who want the drop-to-stage-0 behavior
check the return status, though, so this means all remaining unmerged
entries remain in the index and the callers proceed assuming otherwise.
Users then see errors of the form:

    error: 'DIR-OR-FILE' appears as both a file and as a directory
    error: DIR-OR-FILE: cannot drop to stage #0

and potentially also messages about other unmerged entries which came
lexicographically later than whatever pathname was both a file and a
directory.  Google finds a few hits searching for those messages,
suggesting there were probably a couple people who hit this besides me.
Luckily, calling `git reset --hard` multiple times would workaround
this bug.

Since the whole purpose here is to just put the entry *temporarily* into
the index so that any associated file in the working copy can be removed,
we can just skip the DFCHECK and allow both the file and directory to
appear in the index.  The temporary simultaneous appearance of the
directory and file entries in the index will be removed by the callers
by calling unpack_trees(), which excludes these unmerged entries marked
with CE_CONFLICTED flag from the resulting index, before they attempt to
write the index anywhere.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-31 12:51:11 -07:00
Junio C Hamano d45366e8aa merge: deprecate 'git merge <message> HEAD <commit>' syntax
We had this in "git merge" manual for eternity:

    'git merge' <msg> HEAD <commit>...

    [This] syntax (<msg> `HEAD` <commit>...) is supported for
    historical reasons.  Do not use it from the command line or in
    new scripts.  It is the same as `git merge -m <msg> <commit>...`.

With the update to "git merge" to make it understand what is
recorded in FETCH_HEAD directly, including Octopus merge cases, we
now can rewrite the use of this syntax in "git pull" with a simple
"git merge FETCH_HEAD".

Also there are quite a few fallouts in the test scripts, and it
turns out that "git cvsimport" also uses this old syntax to record
a merge.

Judging from this result, I would not be surprised if dropping the
support of the old syntax broke scripts people have written and been
relying on for the past ten years.  But at least we can start the
deprecation process by throwing a warning message when the syntax is
used.

With luck, we might be able to drop the support in a few years.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-29 13:28:10 -07:00
Elijah Newren f0fd4d05e8 merge-recursive: Fix sorting order and directory change assumptions
We cannot assume that directory/file conflicts will appear in sorted
order; for example, 'letters.txt' comes between 'letters' and
'letters/file'.

Thanks to Johannes for a pointer about qsort stability issues with
Windows and suggested code change.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14 14:19:34 -07:00
Junio C Hamano 5acb623b72 Merge branch 'en/merge-recursive'
* en/merge-recursive: (41 commits)
  t6022: Use -eq not = to test output of wc -l
  merge-recursive:make_room_for_directories - work around dumb compilers
  merge-recursive: Remove redundant path clearing for D/F conflicts
  merge-recursive: Make room for directories in D/F conflicts
  handle_delete_modify(): Check whether D/F conflicts are still present
  merge_content(): Check whether D/F conflicts are still present
  conflict_rename_rename_1to2(): Fix checks for presence of D/F conflicts
  conflict_rename_delete(): Check whether D/F conflicts are still present
  merge-recursive: Delay modify/delete conflicts if D/F conflict present
  merge-recursive: Delay content merging for renames
  merge-recursive: Delay handling of rename/delete conflicts
  merge-recursive: Move handling of double rename of one file to other file
  merge-recursive: Move handling of double rename of one file to two
  merge-recursive: Avoid doubly merging rename/add conflict contents
  merge-recursive: Update merge_content() call signature
  merge-recursive: Update conflict_rename_rename_1to2() call signature
  merge-recursive: Structure process_df_entry() to handle more cases
  merge-recursive: Have process_entry() skip D/F or rename entries
  merge-recursive: New function to assist resolving renames in-core only
  merge-recursive: New data structures for deferring of D/F conflicts
  ...

Conflicts:
	t/t6020-merge-df.sh
	t/t6036-recursive-corner-cases.sh
2010-11-29 17:52:35 -08:00
Ævar Arnfjörð Bjarmason 892e6f7ea6 test-lib: make test_expect_code a test command
Change test_expect_code to be a normal test command instead of a
top-level command.

As a top-level command it would fail in cases like:

    test_expect_code 1 'phoney' '
        foo && bar && (exit 1)
    '

Here the test might incorrectly succeed if "foo" or "bar" happened to
fail with exit status 1. Instead we now do:

    test_expect_success 'phoney' '
        foo && bar && test_expect_code 1 "(exit 1)"
    '

Which will only succeed if "foo" and "bar" return status 0, and "(exit
1)" returns status 1.  Note that test_expect_code has been made slightly
noisier, as it reports the exit code it receives even upon success.

Some test code in t0000-basic.sh relied on the old semantics of
test_expect_code to test the test_when_finished command. I've
converted that code to use an external test similar to the TODO test I
added in v1.7.3-rc0~2^2~3.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-06 13:26:11 -07:00
Elijah Newren ef02b31721 merge-recursive: Make room for directories in D/F conflicts
When there are unmerged entries present, make sure to check for D/F
conflicts first and remove any files present in HEAD that would be in the
way of creating files below the correspondingly named directory.  Such
files will be processed again at the end of the merge in
process_df_entry(); at that time we will be able to tell if we need to
and can reinstate the file, whether we need to place its contents in a
different file due to the directory still being present, etc.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29 17:37:05 -07:00
Elijah Newren 84a08a47b9 handle_delete_modify(): Check whether D/F conflicts are still present
If all the paths below some directory involved in a D/F conflict were not
removed during the rest of the merge, then the contents of the file whose
path conflicted needs to be recorded in file with an alternative filename.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29 17:37:05 -07:00
Elijah Newren fa0ae3b1dd t6020: Add a testcase for modify/delete + directory/file conflict
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29 17:32:37 -07:00
Elijah Newren d09c0a3935 t6020: Modernize style a bit
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29 17:32:37 -07:00
Elijah Newren 5a2580d62f merge_recursive: Fix renames across paths below D/F conflicts
The rename logic in process_renames() handles renames and merging of file
contents and then marks files as processed.  However, there may be higher
stage entries left in the index for other reasons (e.g., due to D/F
conflicts).  By checking for such cases and marking the entry as not
processed, it allows process_entry() later to look at it and handle those
higher stages.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-09 16:13:00 -07:00
Alex Riesen 1c9b2d3aa1 Add a reminder test case for a merge with F/D transition
The problem is that if a file was replaced with a directory containing
another file with the same content and mode, an attempt to merge it
with a branch descended from a commit before this F->D transition will
cause merge-recursive to break. It breaks even if there were no
conflicting changes on that other branch.

Originally reported by Anders Melchiorsen.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29 10:26:10 -07:00
Fredrik Kuivinen 72d1216a04 New test case: merge with directory/file conflicts
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-03 12:29:05 -08:00