conflict_rename_rename_1to2(): Fix checks for presence of D/F conflicts
This function is called from process_df_entry(), near the end of the merge.
Rather than just checking whether one of the sides of the merge had a
directory at the same path as one of our files, check whether that
directory is still present by this point of our merge.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
conflict_rename_delete(): 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>
merge-recursive: Delay modify/delete conflicts if D/F conflict present
When handling merges with modify/delete conflicts, if the modified path is
involved in a D/F conflict, handle the issue in process_df_entry() rather
than process_entry().
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive: Move handling of double rename of one file to other file
Move the handling of rename/rename conflicts where one file is renamed on
both sides to the same file, from process_renames() to process_entry().
Here we avoid the three way merge logic by just using
update_stages_and_entry() to move the higher stage entries in the index
from the rename source to the rename destination, and then allow
process_entry() to do its magic.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a commit moves A to B while another commit created B (or moved C to
B), and these two different commits serve as different merge-bases for a
later merge, c94736a (merge-recursive: don't segfault while handling
rename clashes 2009-07-30) added some special code to avoid segfaults.
Since that commit, the two versions of B are merged in place (which could
be potentially conflicting) and the intermediate result is used as the
virtual ancestor.
However, right before this special merge, try_merge was turned on, meaning
that process_renames() would try an alternative merge that ignores the
'add' part of the conflict, and, if the merge is clean, store that as the
new virtual ancestor. This could cause incorrect merging of criss-cross
merges; it would typically result in just recording a slightly confusing
merge base, but in some cases it could cause silent acceptance of one side
of a merge as the final resolution when a conflict should have been
flagged.
When we do a special merge for such a rename/add conflict between
merge-bases, turn try_merge off to avoid an inappropriate second merge.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
To facilitate having this function called later using information stored
in a rename_df_conflict_info struct, accept a diff_filepair instead of a
rename.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive: New function to assist resolving renames in-core only
process_renames() and process_entry() have nearly identical code for
doing three-way file merging to resolve content changes. Since we are
already deferring some of the current rename handling in order to better
handle D/F conflicts, it seems to make sense to defer content merging as
well and remove the (nearly) duplicated code sections for handling this
merging.
To facilitate this process, add a new update_stages_and_entry() function
which will map the higher stage index entries from two files involved in a
rename into the resulting rename destination's index entries, and update
the associated stage_data structure.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive: New data structures for deferring of D/F conflicts
Since we need to resolve paths (including renames) in-core first and defer
checking of D/F conflicts (namely waiting to see if directories are still
in the way after all paths are resolved) before updating files involved in
D/F conflicts, we will need to first process_renames, then record some
information about the rename needed at D/F resolution time, and then make
use of that information when resolving D/F conflicts at the end.
This commit adds some relevant data structures for storing the necessary
information.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive: Move process_entry's content merging into a function
This move is in preparation for merge_content growing and being called from
multiple places in order to handle D/F conflicts.
I also snuck in a small change to the output in the case that the merged
content for the file matches the current file contents, to make it better
match (and thus more able to take over) how other merge_file() calls in
process_renames() are handled.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since we want to resolve merges in-core and then detect at the end whether
D/F conflicts remain in the way, we should just apply renames in-core and
let logic elsewhere check for D/F conflicts.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive: Rename conflict_rename_rename*() for clarity
The names conflict_rename_rename and conflict_rename_rename_2 did not make
it clear what they were handling. Since the first of these handles one
file being renamed in both branches to different files, while the latter
handles two different files being renamed to the same thing, add a little
'1to2' and '2to1' suffix on these and an explanatory comment to make their
intent clearer.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive: Small code clarification -- variable name and comments
process_renames() had a variable named "stage" and derived variables
src_other and dst_other whose purpose was not immediately obvious; also,
I want to extend the scope of this variable and use it later, so it should
have a more descriptive name. Do so, and add a brief comment explaining
how it is used and what it relates to.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If merging two lines of development involves a rename/add conflict, and two
different people make such a merge but resolve it differently, and then
someone tries to merge the resulting two merges, then they should clearly
get a conflict due to the different resolutions from the previous
developers. However, in some such cases the conflict would not be detected
and git would silently accept one of the two versions being merged as the
final merge resolution.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t6036: Add a second testcase similar to the first but with content changes
c94736a (merge-recursive: don't segfault while handling rename clashes
2009-07-30) added t6036 with a testcase that involved dual renames and a
criss-cross merge. Add a test that is nearly identical, but which also
involves content modification -- a case git currently does not merge
correctly.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t6036: Test index and worktree state, not just that merge fails
c94736a (merge-recursive: don't segfault while handling rename clashes
2009-07-30) added this testcase with an interesting corner case test,
which previously had cased git to segfault. This test ensures that the
segfault does not return and that the merge correctly fails; just add
some checks that verify the state of the index and worktree after the merge
are correct.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t6022: Add tests for rename/rename combined with D/F conflicts
Add tests where one file is renamed to two different paths in different
sides of history, and where each of the new files matches the name of a
directory from the opposite side of history. Include tests for both the
case where the merge results in those directories not being cleanly
removed, and where those directories are cleanly removed during the merge.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
An interesting testcase is having two files each in their own subdirectory
getting renamed to the toplevel at the directory pathname of the other.
Questions arise as to whether the order of operations matters and whether
the directories can correctly get out of the way and make room for the
new files.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t6022: Add tests with both rename source & dest involved in D/F conflicts
Having the source of a rename be involved in a directory/file conflict does
not currently pose any difficulties to the current merge-recursive
algorithm (in contrast to destinations of renames and D/F conflicts).
However, combining the two seemed like good testcases to include for
completeness.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t6022: Add tests for reversing order of merges when D/F conflicts present
When merging two branches with some path involved in a D/F conflict, the
choice of which branch to merge into the other matters for (at least) two
reasons: (1) whether the working copy has a directory full of files that
is in the way of a file, or a file exists that is in the way of a
directory of files, (2) when the directory full of files does not disappear
due to the merge, what files at the same paths should be renamed to
(e.g. filename~HEAD vs. filename~otherbranch).
Add some tests that reverse the merge order of two other tests, and which
verify the contents are as expected (namely, that the results are identical
other than modified-for-uniqueness filenames involving branch names).
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t6022: Add test combinations of {content conflict?, D/F conflict remains?}
Add testing of the various ways that a renamed file to a path involved in
a directory/file conflict may be involved in. This includes whether or not
there are conflicts of the contents of the renamed file (if the file was
modified on both sides of history), and whether the directory from the
other side of the merge will disappear as a result of the merge or not.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t6032: Add a test checking for excessive output from merge
Previous D/F fixes I submitted (5a2580d and ae74548) had caused merge to
become excessively spammy, which was fixed in 96ecac6 (merge-recursive:
Avoid excessive output for and reprocessing of renames 2010-08-20). Add a
new test to avoid repeating that mistake with my several upcoming changes.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive: Restructure showing how to chain more process_* functions
In 3734893 (merge-recursive: Fix D/F conflicts 2010-07-09),
process_df_entry() was added to process_renames() and process_entry() but
in a somewhat restrictive manner. Modify the code slightly to make it
clearer how we could chain more such functions if necessary, and alter
process_df_entry() to handle such chaining.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t3030: Add a testcase for resolvable rename/add conflict with symlinks
d5af510 (RE: [PATCH] Avoid rename/add conflict when contents are identical
2010-09-01) avoided erroring out in a rename/add conflict when the contents
were identical. A simpler fix could have handled that particular testcase,
but it would not correctly handle the case where a symlink is involved.
Add another testcase using symlinks, to avoid breaking that case.
Signed-off-by: Ken Schalk <ken.schalk@intel.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-rebase--interactive.sh: replace cut with ${v%% *}
Some versions of cut do not cope well with lines that do not end in
an LF. In this case, we can completely avoid cut by using the
${var%% *} parameter expansion (suggested by Brandon Casey).
I found this problem when t3404's "avoid unnecessary reset" failed
due to the "rebase -i" not avoiding updating the tested timestamp.
t/t7300: workaround ancient touch by rearranging arguments
The ancient touch on Solaris 7 thinks that a decimal number supplied as
the first argument specifies a date_time to give to the files specified by
the remaining arguments. In this case, it fails to parse '1' as a proper
date_time and exits with a failure status. Workaround this flaw by
rearranging the arguments supplied to touch so that a non-digit appears
first and touch will not be confused.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Similar to descriptions of other options, state what -x does in imperative
mood. Start sentences for -X and --exclude-per-directory options in
capital letters.
Since b5227d8, -x/--exclude does not apply to cached files.
This is easy to miss unless you read the discussion in the
EXCLUDE PATTERNS section. Clarify that the option applies
to untracked files and direct the reader to EXCLUDE PATTERNS.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jl/fix-test:
t1020: Get rid of 'cd "$HERE"' at the start of each test
t2016 (checkout -p): add missing &&
t1302 (core.repositoryversion): style tweaks
t2105 (gitfile): add missing &&
t1450 (fsck): remove dangling objects
tests: subshell indentation stylefix
Several tests: cd inside subshell instead of around
* 'master' of git://repo.or.cz/git-gui:
git-gui 0.13
git-gui: avoid mis-encoding the copyright message on Windows.
git-gui: Update Swedish translation (521t).
git-gui: ensure correct application termination in git-gui--askpass
git-gui: handle textconv filter on Windows and in development
git-gui: use shell to launch textconv filter in "blame"
git-gui: display error launching blame as a message box.
git-gui: Make usage statement visible on Windows.
git-gui: avoid mis-encoding the copyright message on Windows.
On Windows the tcl script file will use the system encoding and attempting
to convert the copyright mis-encodes the string. Instead, keep the message
as ASCII and substitute in the correct unicode character when running.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
t7003-filter-branch.sh had a make_commit() function that was identical
to test_commit() in test-lib.sh except that it used tr to create a
lowercase file name from the uppercase branch name instead of
appending ".t".
Not only is this unneeded code duplication, it also was something
simply waiting to fail on case-insensitive file systems. So replace
all uses of make_commit with test_commit.
While we're editing the setup, chain it together with && so that
failures early in the sequence don't get lost and add a commit graph.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, on systems that define uint32_t as an unsigned long,
gcc complains as follows:
CC vcs-svn/fast_export.o
vcs-svn/fast_export.c: In function `fast_export_modify':
vcs-svn/fast_export.c:28: warning: unsigned int format, uint32_t arg (arg 2)
vcs-svn/fast_export.c:28: warning: int format, uint32_t arg (arg 3)
vcs-svn/fast_export.c: In function `fast_export_commit':
vcs-svn/fast_export.c:42: warning: int format, uint32_t arg (arg 5)
vcs-svn/fast_export.c:62: warning: int format, uint32_t arg (arg 2)
vcs-svn/fast_export.c: In function `fast_export_blob':
vcs-svn/fast_export.c:72: warning: int format, uint32_t arg (arg 2)
vcs-svn/fast_export.c:72: warning: int format, uint32_t arg (arg 3)
CC vcs-svn/svndump.o
vcs-svn/svndump.c: In function `svndump_read':
vcs-svn/svndump.c:260: warning: int format, uint32_t arg (arg 3)
In order to suppress the warnings we use the C99 format specifier
macros PRIo32 and PRIu32 from <inttypes.h>.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
compat/nedmalloc: don't force NDEBUG on the rest of git
Define the nedmalloc feature configuration macros for nedmalloc.o, only.
This keeps assert(3) working for the rest of the git source; it was
turned off for nedmalloc users before by defining NDEBUG globally.
Also remove -DUSE_NED_ALLOCATOR as this macro isn't used anywhere.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In git-config(1), diff.noprefix was placed in between
diff.mnemonicprefix and the list of mnemonic prefixes, which is
obviously incorrect and very confusing to readers. Now, it is located
after the end of the explanation of mnemonicprefix, which makes much
more sense.
Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t4018: test whether the word_regex patterns compile
Previously (e3bf5e43), a test was added to test whether the builtin
xfuncname regular expressions could be compiled without error by regcomp.
Let's do the same for the word_regex patterns. This should help catch any
cross-platform incompatibilities that exist between the pattern creator's
system and the various platforms that the test suite is commonly run on.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
xdiff-interface.c: always trim trailing space from xfuncname matches
Generally, trailing space is removed from the string matched by the
xfuncname patterns. The exception is when the matched string exceeds the
length of the fixed-size buffer that it will be copied in to. But, a
string that exceeds the buffer can still contain trailing space in the
portion of the string that will be copied into the buffer. So, simplify
this code slightly, and just perform the trailing space removal always.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t5510-fetch.sh: improve testing with explicit URL and merge spec
Commit 6106ce46 introduced a test to demonstrate fetch's failure to
retrieve any objects or update FETCH_HEAD when it was supplied a repository
URL and the current branch had a configured merge spec. This commit
expands the original test based on comments from Junio Hamano. In addition
to actually verifying that the fetch updates FETCH_HEAD correctly, and does
not update the current branch, two more tests are added to ensure that the
merge configuration is ignored even when the supplied URL matches the URL
of the remote configured for the branch.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/fetch.c: comment that branch->remote_name is usable when has_merge
Save future readers the trouble of tracing code to determine that the two
uses of branch->remote_name are safe when has_merge is set, by adding a
comment explaining that it is so.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The IRIX 6.5 regex.h header file defines REG_STARTEND, but the feature does
not appear to work. Since REG_STARTEND is required for proper functioning
of git-grep, set NO_REGEX and use the alternative regex libraries in compat/
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t7008: workaround broken handling of \000 by printf on IRIX
On IRIX 6.5, the printf utility in /usr/bin does not appear to handle the
\ddd notation according to POSIX. This printf appears to halt processing
of the string argument and ignore any additional characters in the string.
Work around this flaw by replacing the \000's with 'Q' and using the
q_to_nul helper function provided by test-lib.sh
This problem with printf is not apparent when using the Bash shell since
Bash implements a POSIX compatible printf function internally.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive: D/F conflicts where was_a_dir/file -> was_a_dir
In merge-recursive.c, whenever there was a rename where a file name on one
side of the rename matches a directory name on the other side of the merge,
then the very first check that
would trigger forcing it into marking it as a rename/directory conflict.
However, if the path is only renamed on one side and a simple three-way
merge between the separate files resolves cleanly, then we don't need to
mark it as a rename/directory conflict. So, we can simply move the check
for rename/directory conflicts after we've verified that there isn't a
rename/rename conflict and that a threeway content merge doesn't work.
This changes the particular error message one gets in the case where the
directory name that a file on one side of the rename matches is not also
part of the rename pair. For example, with commits containing the files:
then previously when one tried to merge MERGE into HEAD, one would get
CONFLICT (rename/directory): Rename sub/file1->newsub in HEAD directory newsub added in merge
Renaming sub/file1 to newsub~HEAD instead
Adding newsub/newfile
Automatic merge failed; fix conflicts and then commit the result.
After this patch, the error message will instead become:
Removing newsub
Adding newsub/newfile
CONFLICT (file/directory): There is a directory with name newsub in merge. Adding newsub as newsub~HEAD
Automatic merge failed; fix conflicts and then commit the result.
That makes more sense to me, because git can't know that there's a conflict
until after it's tried resolving paths involving newsub/newfile to see if
they are still in the way at the end (and if newsub/newfile is not in the
way at the end, there should be no conflict at all, which did not hold with
git previously).
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When one side of a file rename matches a directory name on the other side,
the recursive merge strategy will fail. This is true even if the merge is
trivially resolvable.
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test is from 2007, which is late enough for the style to be
recognizably modern but still a while ago. Freshen it up to
follow new best practices:
- guard setup commands with test_expect_setup, so errors at
that stage can be caught;
- use <<\EOF in preference to <<EOF, to save reviewers the
trouble of looking for variable interpolations;
- use test_cmp instead of test "$foo" = "$bar", for better
output with -v on failure;
- indent commands in subshells and let them span multiple lines;
- combine the two "gitdir required mode" tests that do not make
as much sense alone.
Cc: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fsck test is generally careful to remove the corrupt objects
it inserts, but dangling objects are left behind due to some typos
and omissions. It is better to clean up more completely, to
simplify the addition of later tests. So:
- guard setup and cleanup with test_expect_success to catch
typos and errors;
- check both stdout and stderr when checking for empty fsck
output;
- use test_cmp empty file in place of test $(wc -l <file) = 0,
for better debugging output when running tests with -v;
- add a remove_object () helper and use it to replace broken
object removal code that forgot about the fanout in
.git/objects;
- disable gc.auto, to avoid tripping up object removal if the
number of objects ever reaches that threshold.
- use test_when_finished to ensure cleanup tasks are run and
succeed when tests fail;
- add a new final test that no breakage or dangling objects
was left behind.
While at it, add a brief description to test_description of the
history that is expected to persist between tests.
Part of a campaign to clean up subshell usage in tests.
Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Format the subshells introduced by the previous patch (Several tests:
cd inside subshell instead of around, 2010-09-06) like so:
(
cd subdir &&
...
) &&
This is generally easier to read and has the nice side-effect that
this patch will show what commands are used in the subshell, making
it easier to check for lost environment variables and similar
behavior changes.
Cc: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/test-must-fail-missing:
tests: make test_might_fail fail on missing commands
tests: make test_might_fail more verbose
tests: make test_must_fail fail on missing commands
tests: make test_must_fail more verbose
* kf/askpass-config:
Extend documentation of core.askpass and GIT_ASKPASS.
Allow core.askpass to override SSH_ASKPASS.
Add a new option 'core.askpass'.
* bc/maint-fetch-url-only:
builtin/fetch.c: ignore merge config when not fetching from branch's remote
t/t5510: demonstrate failure to fetch when current branch has merge ref
fast-export: ensure that a renamed file is printed after all references
t9350 sets up a commit where a file is both copied and renamed. The output
of fast-export for this commit should look like this:
author ...
committer ...
from :19
C "file2" "file4"
R "file2" "file5"
The order of the two modification lines is derived from the result that
the diff machinery produces.
060df62 (fast-export: Fix output order of D/F changes) inserted a qsort
call that modifies the order of the diff result. Unfortunately, qsort need
not be stable. Therefore, it is possible that the 'R' line appears before
the 'C' line and the resulting fast-import stream is incorrect.
Fix it by forcing that the rename entry is printed after all other
modification lines with the same file name.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>