Elijah Newren [Fri, 12 Aug 2011 05:20:22 +0000 (23:20 -0600)]
merge-recursive: Fix working copy handling for rename/rename/add/add
If either side of a rename/rename(1to2) conflict is itself also involved
in a rename/add-dest conflict, then we need to make sure both the rename
and the added file appear in the working copy.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:21 +0000 (23:20 -0600)]
merge-recursive: add handling for rename/rename/add-dest/add-dest
Each side of the rename in rename/rename(1to2) could potentially also be
involved in a rename/add conflict. Ensure stages for such conflicts are
also recorded.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:20 +0000 (23:20 -0600)]
merge-recursive: Have conflict_rename_delete reuse modify/delete code
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:19 +0000 (23:20 -0600)]
merge-recursive: Make modify/delete handling code reusable
modify/delete and rename/delete share a lot of similarities; we'd like all
the criss-cross and D/F conflict handling specializations to be shared
between the two.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:18 +0000 (23:20 -0600)]
merge-recursive: Consider modifications in rename/rename(2to1) conflicts
Our previous conflict resolution for renaming two different files to the
same name ignored the fact that each of those files may have modifications
from both sides of history to consider. We need to do a three-way merge
for each of those files, and then handle the conflict of both sets of
merged contents trying to be recorded with the same name.
It is important to note that this changes our strategy in the recursive
case. After doing a three-way content merge of each of the files
involved, we still are faced with the fact that we are trying to put both
of the results (including conflict markers) into the same path. We could
do another two-way merge, but I think that becomes confusing. Also,
taking a hint from the modify/delete and rename/delete cases we handled
earlier, a more useful "common ground" would be to keep the three-way
content merge but record it with the original filename. The renames can
still be detected, we just allow it to be done in the o->call_depth=0
case. This seems to result in simpler & easier to understand merge
conflicts as well, as evidenced by some of the changes needed in our
testsuite in t6036. (However, it should be noted that this change will
cause problems those renames also occur along with a file being added
whose name matches the source of the rename. Since git currently cannot
detect rename/add-source situations, though, this codepath is not
currently used for those cases anyway.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:17 +0000 (23:20 -0600)]
merge-recursive: Create function for merging with branchname:file markers
We want to be able to reuse the code to do a three-way file content merge
and have the conflict markers use both branchname and filename. Split it
out into a separate function.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:16 +0000 (23:20 -0600)]
merge-recursive: Record more data needed for merging with dual renames
When two different files are renamed to one, we need to be able to do
three-way merges for both of those files. To do that, we need to record
the sha1sum of the (possibly modified) file on the unrenamed side. Modify
setup_rename_conflict_info() to take this extra information and record it
when the rename_type is RENAME_TWO_FILES_TO_ONE.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:15 +0000 (23:20 -0600)]
merge-recursive: Defer rename/rename(2to1) handling until process_entry
This puts the code for the different types of double rename conflicts
closer together (fewer lines of other code separating the two paths) and
increases similarity between how they are handled.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:14 +0000 (23:20 -0600)]
merge-recursive: Small cleanups for conflict_rename_rename_1to2
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:13 +0000 (23:20 -0600)]
merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base
When renaming one file to two files, we really should be doing a content
merge. Also, in the recursive case, undoing the renames and recording the
merged file in the index with the source of the rename (while deleting
both destinations) allows the renames to be re-detected in the
non-recursive merge and will result in fewer spurious conflicts.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:12 +0000 (23:20 -0600)]
merge-recursive: Introduce a merge_file convenience function
merge_file previously required diff_filespec arguments, but all callers
only had sha1s and modes. Rename merge_file to merge_file_1 and introduce
a new merge_file convenience function which takes the sha1s and modes and
creates the temporary diff_filespec variables needed to call merge_file_1.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:11 +0000 (23:20 -0600)]
merge-recursive: Fix modify/delete resolution in the recursive case
When o->call_depth>0 and we have conflicts, we try to find "middle ground"
when creating the virtual merge base. In the case of content conflicts,
this can be done by doing a three-way content merge and using the result.
In all parts where the three-way content merge is clean, it is the correct
middle ground, and in parts where it conflicts there is no middle ground
but the conflict markers provide a good compromise since they are unlikely
to accidentally match any further changes.
In the case of a modify/delete conflict, we cannot do the same thing.
Accepting either endpoint as the resolution for the virtual merge base
runs the risk that when handling the non-recursive case we will silently
accept one person's resolution over another without flagging a conflict.
In this case, the closest "middle ground" we have is actually the merge
base of the candidate merge bases. (We could alternatively attempt a
three way content merge using an empty file in place of the deleted file,
but that seems to be more work than necessary.)
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:10 +0000 (23:20 -0600)]
merge-recursive: When we detect we can skip an update, actually skip it
In
882fd11 (merge-recursive: Delay content merging for renames 2010-09-20),
there was code that checked for whether we could skip updating a file in
the working directory, based on whether the merged version matched the
current working copy. Due to the desire to handle directory/file conflicts
that were resolvable, that commit deferred content merging by first
updating the index with the unmerged entries and then moving the actual
merging (along with the skip-the-content-update check) to another function
that ran later in the merge process. As part moving the content merging
code, a bug was introduced such that although the message about skipping
the update would be printed (whenever GIT_MERGE_VERBOSITY was sufficiently
high), the file would be unconditionally updated in the working copy
anyway.
When we detect that the file does not need to be updated in the working
copy, update the index appropriately and then return early before updating
the working copy.
Note that there was a similar change in
b2c8c0a (merge-recursive: When we
detect we can skip an update, actually skip it 2011-02-28), but it was
reverted by
6db4105 (Revert "Merge branch 'en/merge-recursive'"
2011-05-19) since it did not fix both of the relevant types of unnecessary
update breakages and, worse, it made use of some band-aids that caused
other problems. The reason this change works is due to the changes earlier
in this series to (a) record_df_conflict_files instead of just unlinking
them early, (b) allowing make_room_for_path() to remove D/F entries,
(c) the splitting of update_stages_and_entry() to have its functionality
called at different points, and (d) making the pathnames of the files
involved in the merge available to merge_content().
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:09 +0000 (23:20 -0600)]
merge-recursive: Provide more info in conflict markers with file renames
Whenever there are merge conflicts in file contents, we would mark the
different sides of the conflict with the two branches being merged.
However, when there is a rename involved as well, the branchname is not
sufficient to specify where the conflicting content came from. In such
cases, mark the two sides of the conflict with branchname:filename rather
than just branchname.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:08 +0000 (23:20 -0600)]
merge-recursive: Cleanup and consolidation of rename_conflict_info
The consolidation of process_entry() and process_df_entry() allows us to
consolidate more code paths concerning rename conflicts, and to do
a few additional related cleanups. It also means we are using
rename_df_conflict_info in some cases where there is no D/F conflict;
rename it to rename_conflict_info.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:07 +0000 (23:20 -0600)]
merge-recursive: Consolidate process_entry() and process_df_entry()
The whole point of adding process_df_entry() was to ensure that files of
D/F conflicts were processed after paths under the corresponding
directory. However, given that the entries are in sorted order, all we
need to do is iterate through them in reverse order to achieve the same
effect. That lets us remove some duplicated code, and lets us keep
track of one less thing as we read the code ("do we need to make sure
this is processed before process_df_entry() or do we need to defer it
until then?").
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:06 +0000 (23:20 -0600)]
merge-recursive: Improve handling of rename target vs. directory addition
When dealing with file merging and renames and D/F conflicts and possible
criss-cross merges (how's that for a corner case?), we did not do a
thorough job ensuring the index and working directory had the correct
contents. Fix the logic in merge_content() to handle this. Also,
correct some erroneous tests in t6022 that were expecting the wrong number
of unmerged index entries. These changes fix one of the tests in t6042
(and almost fix another one from t6042 as well).
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:05 +0000 (23:20 -0600)]
merge-recursive: Add comments about handling rename/add-source cases
There are a couple of places where changes are needed to for situations
involving rename/add-source issues. Add comments about the needed changes
(and existing bugs) until git has been enabled to detect such cases.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:04 +0000 (23:20 -0600)]
merge-recursive: Make dead code for rename/rename(2to1) conflicts undead
The code for rename_rename_2to1 conflicts (two files both being renamed to
the same filename) was dead since the rename/add path was always being
independently triggered for each of the renames instead. Further,
reviving the dead code showed that it was inherently buggy and would
always segfault -- among a few other bugs.
Move the else-if branch for the rename/rename block before the rename/add
block to make sure it is checked first, and fix up the rename/rename(2to1)
code segments to make it handle most cases. Work is still needed to
handle higher dimensional corner cases such as rename/rename/modify/modify
issues.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:03 +0000 (23:20 -0600)]
merge-recursive: Fix deletion of untracked file in rename/delete conflicts
In the recursive case (o->call_depth > 0), we do not modify the working
directory. However, when o->call_depth==0, file renames can mean we need
to delete the old filename from the working copy. Since there have been
lots of changes and mistakes here, let's go through the details. Let's
start with a simple explanation of what we are trying to achieve:
Original goal: If a file is renamed on the side of history being merged
into head, the filename serving as the source of that rename needs to be
removed from the working directory.
The path to getting the above statement implemented in merge-recursive took
several steps. The relevant bits of code may be instructive to keep in
mind for the explanation, especially since an English-only description
involves double negatives that are hard to follow. These bits of code are:
int remove_file(..., const char *path, int no_wd)
{
...
int update_working_directory = !o->call_depth && !no_wd;
and
remove_file(o, 1, ren1_src, <expression>);
Where the choice for <expression> has morphed over time:
65ac6e9 (merge-recursive: adjust to loosened "working file clobbered"
check 2006-10-27), introduced the "no_wd" parameter to remove_file() and
used "1" for <expression>. This meant ren1_src was never deleted, leaving
it around in the working copy.
In
8371234 (Remove uncontested renamed files during merge. 2006-12-13),
<expression> was changed to "index_only" (where index_only ==
!!o->call_depth; see
b7fa51da). This was equivalent to using "0" for
<expression> (due to the early logic in remove_file), and is orthogonal to
the condition we actually want to check at this point; it resulted in the
source file being removed except when index_only was false. This was
problematic because the file could have been renamed on the side of history
including head, in which case ren1_src could correspond to an untracked
file that should not be deleted.
In
183d797 (Keep untracked files not involved in a merge. 2007-02-04),
<expression> was changed to "index_only || stage == 3". While this gives
correct behavior, the "index_only ||" portion of <expression> is
unnecessary and makes the code slightly harder to follow.
There were also two further changes to this expression, though without
any change in behavior. First in
b7fa51d (merge-recursive: get rid of the
index_only global variable 2008-09-02), it was changed to "o->call_depth
|| stage == 3". (index_only == !!o->call_depth). Later, in
41d70bd6
(merge-recursive: Small code clarification -- variable name and comments),
this was changed to "o->call_depth || renamed_stage == 2" (where stage was
renamed to other_stage and renamed_stage == other_stage ^ 1).
So we ended with <expression> being "o->call_depth || renamed_stage == 2".
But the "o->call_depth ||" piece was unnecessary. We can remove it,
leaving us with <expression> being "renamed_stage == 2". This doesn't
change behavior at all, but it makes the code clearer. Which is good,
because it's about to get uglier.
Corrected goal: If a file is renamed on the side of history being merged
into head, the filename serving as the source of that rename needs to be
removed from the working directory *IF* that file is tracked in head AND
the file tracked in head is related to the original file.
Note that the only difference between the original goal and the corrected
goal is the two extra conditions added at the end. The first condition is
relevant in a rename/delete conflict. If the file was deleted on the
HEAD side of the merge and an untracked file of the same name was added to
the working copy, then without that extra condition the untracked file
will be erroneously deleted. This changes <expression> to "renamed_stage
== 2 || !was_tracked(ren1_src)".
The second additional condition is relevant in two cases.
The first case the second condition can occur is when a file is deleted
and a completely different file is added with the same name. To my
knowledge, merge-recursive has no mechanism for detecting deleted-and-
replaced-by-different-file cases, so I am simply punting on this
possibility.
The second case for the second condition to occur is when there is a
rename/rename/add-source conflict. That is, when the original file was
renamed on both sides of history AND the original filename is being
re-used by some unrelated (but tracked) content. This case also presents
some additional difficulties for us since we cannot currently detect these
rename/rename/add-source conflicts; as long as the rename detection logic
"optimizes" by ignoring filenames that are present at both ends of the
diff, these conflicts will go unnoticed. However, rename/rename conflicts
are handled by an entirely separate codepath not being discussed here, so
this case is not relevant for the line of code under consideration.
In summary:
Change <expression> from "o->call_depth || renamed_stage == 2" to
"renamed_stage == 2 || !was_tracked(ren1_src)", in order to remove
unnecessary code and avoid deleting untracked files.
96 lines of explanation in the changelog to describe a one-line fix...
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:02 +0000 (23:20 -0600)]
merge-recursive: Split update_stages_and_entry; only update stages at end
Instead of having the process_renames logic update the stages in the index
for the rename destination, have the index updated after process_entry or
process_df_entry. This will also allow us to have process_entry determine
whether a file was tracked and existed in the working copy before the
merge started.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:20:01 +0000 (23:20 -0600)]
merge-recursive: Allow make_room_for_path() to remove D/F entries
If there were several files conflicting below a directory corresponding
to a D/F conflict, and the file of that D/F conflict is in the way, we
want it to be removed. Since files of D/F conflicts are handled last,
they can be reinstated later and possibly with a new unique name.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes Sixt [Fri, 12 Aug 2011 05:20:00 +0000 (23:20 -0600)]
string-list: Add API to remove an item from an unsorted list
Teach the string-list API how to remove an entry in O(1) runtime by
moving the last entry to the vacated spot. As such, the routine works
only for unsorted lists.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:59 +0000 (23:19 -0600)]
merge-recursive: Split was_tracked() out of would_lose_untracked()
Checking whether a filename was part of stage 0 or stage 2 is code that we
would like to be able to call from a few other places without also
lstat()-ing the file to see if it exists in the working copy.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:58 +0000 (23:19 -0600)]
merge-recursive: Save D/F conflict filenames instead of unlinking them
Rename make_room_for_directories_of_df_conflicts() to
record_df_conflict_files() to reflect the change in functionality.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:57 +0000 (23:19 -0600)]
merge-recursive: Fix code checking for D/F conflicts still being present
Previously, we were using lstat() to determine if a directory was still
present after a merge (and thus in the way of adding a file). We should
have been using lstat() only to determine if untracked directories were in
the way (and then only when necessary to check for untracked directories);
we should instead using the index to determine if there is a tracked
directory in the way. Create a new function to do this and use it to
replace the existing checks for directories being in the way.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:56 +0000 (23:19 -0600)]
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>
Elijah Newren [Fri, 12 Aug 2011 05:19:55 +0000 (23:19 -0600)]
merge-recursive: Fix recursive case with D/F conflict via add/add conflict
When a D/F conflict is introduced via an add/add conflict, when
o->call_depth > 0 we need to ensure that the higher stage entry from the
base stage is removed.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:54 +0000 (23:19 -0600)]
merge-recursive: Avoid working directory changes during recursive case
make_room_for_directories_of_df_conflicts() is about making sure necessary
working directory changes can succeed. When o->call_depth > 0 (i.e. the
recursive case), we do not want to make any working directory changes so
this function should be skipped.
Note that make_room_for_directories_of_df_conflicts() is broken as has
been pointed out by Junio; it should NOT be unlinking files. What it
should do is keep track of files that could be unlinked if a directory
later needs to be written in their place. However, that work also is only
relevant in the non-recursive case, so this change is helpful either way.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:53 +0000 (23:19 -0600)]
merge-recursive: Remember to free generated unique path names
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:52 +0000 (23:19 -0600)]
merge-recursive: Consolidate different update_stages functions
We are only calling update_stages_options() one way really, so we can
consolidate the slightly different variants into one and remove some
parameters whose values are always the same.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:51 +0000 (23:19 -0600)]
merge-recursive: Mark some diff_filespec struct arguments const
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:50 +0000 (23:19 -0600)]
merge-recursive: Correct a comment
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:49 +0000 (23:19 -0600)]
merge-recursive: Make BUG message more legible by adding a newline
Hopefully no one ever hits this error except when making large changes to
merge-recursive.c and debugging...
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:48 +0000 (23:19 -0600)]
t6022: Add testcase for merging a renamed file with a simple change
This is a testcase that was broken by
b2c8c0a (merge-recursive: When we
detect we can skip an update, actually skip it 2011-02-28) and fixed by
6db4105 (Revert "Merge branch 'en/merge-recursive'" 2011-05-19). Include
this testcase to ensure we don't regress it again.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:47 +0000 (23:19 -0600)]
t6022: New tests checking for unnecessary updates of files
This testcase was part of en/merge-recursive that was reverted in
6db4105
(Revert "Merge branch 'en/merge-recursive'" 2011-05-19). While the other
changes in that series caused unfortunate breakage, this testcase is still
useful; reinstate it.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:46 +0000 (23:19 -0600)]
t6022: Remove unnecessary untracked files to make test cleaner
Since this test later does a git add -A, we should clean out unnecessary
untracked files as part of our cleanup.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:45 +0000 (23:19 -0600)]
t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify
This is another challenging testcase trying to exercise the virtual merge
base creation in the rename/rename(1to2) code. A testcase is added that
we should be able to merge cleanly, but which requires a virtual merge
base to be created that is aware of rename/rename(1to2)/add-source
conflicts and can handle those.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:44 +0000 (23:19 -0600)]
t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modify
This test is mostly just designed for testing optimality of the virtual
merge base in the event of a rename/rename(1to2) conflict. The current
choice for resolving this in git seems somewhat confusing and suboptimal.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:43 +0000 (23:19 -0600)]
t6036: tests for criss-cross merges with various directory/file conflicts
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:42 +0000 (23:19 -0600)]
t6036: criss-cross with weird content can fool git into clean merge
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:41 +0000 (23:19 -0600)]
t6036: Add differently resolved modify/delete conflict in criss-cross test
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:40 +0000 (23:19 -0600)]
t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
Add testcases that cover three failures with current git merge, all
involving renaming one file on both sides of history:
Case 1:
If a single file is renamed to two different filenames on different sides
of history, there should be a conflict. Adding a new file on one of those
sides of history whose name happens to match the rename source should not
cause the merge to suddenly succeed.
Case 2:
If a single file is renamed on both sides of history but renamed
identically, there should not be a conflict. This works fine. However,
if one of those sides also added a new file that happened to match the
rename source, then that file should be left alone. Currently, the
rename/rename conflict handling causes that new file to become untracked.
Case 3:
If a single file is renamed to two different filenames on different sides
of history, there should be a conflict. This works currently. However,
if those renames also involve rename/add conflicts (i.e. there are new
files on one side of history that match the destination of the rename of
the other side of history), then the resulting conflict should be recorded
in the index, showing that there were multiple files with a given filename.
Currently, git silently discards one of file versions.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:39 +0000 (23:19 -0600)]
t6042: Ensure rename/rename conflicts leave index and workdir in sane state
rename/rename conflicts, both with one file being renamed to two different
files and with two files being renamed to the same file, should leave the
index and the working copy in a sane state with appropriate conflict
recording, auxiliary files, etc. Git seems to handle one of the two cases
alright, but has some problems with the two files being renamed to one
case. Add tests for both cases.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:38 +0000 (23:19 -0600)]
t6042: Add tests for content issues with modify/rename/directory conflicts
Add testcases that cover a variety of merge issues with files being
renamed and modified on different sides of history, when there are
directories possibly conflicting with the rename location.
Case 1:
On one side of history, a file is modified and a new directory is added.
On the other side of history, the file is modified in a non-conflicting
way but is renamed to the location of the new directory.
Case 2:
[Same as case 1, but there is also a content conflict. In detail:]
On one side of history, a file is modified and a new directory is added.
On the other side of history, the file is modified in a conflicting way
and it is renamed to the location of the new directory.
Case 3:
[Similar to case 1, but the "conflicting" directory is the directory
where the file original resided. In detail:]
On one side of history, a file is modified. On the other side of history,
the file is modified in a non-conflicting way, but the directory it was
under is removed and the file is renamed to the location of the directory
it used to reside in (i.e. 'sub/file' gets renamed to 'sub'). This is
flagged as a directory/rename conflict, but should be able to be resolved
since the directory can be cleanly removed by the merge.
One branch renames a file and makes a file where the directory the renamed
file used to be in, and the other branch updates the file in
place. Merging them should resolve it cleanly as long as the content level
change on the branches do not overlap and rename is detected, or should
leave conflict without losing information.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:37 +0000 (23:19 -0600)]
t6042: Add a testcase where undetected rename causes silent file deletion
There are cases where history should merge cleanly, and which current git
does merge cleanly despite not detecting a rename; however the merge
currently nukes files that should not be removed.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:36 +0000 (23:19 -0600)]
t6042: Add a pair of cases where undetected renames cause issues
An undetected rename can cause a silent success where a conflict should
have been detected, or can cause an erroneous conflict state where the
merge should have been resolvable. Add testcases for both.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:35 +0000 (23:19 -0600)]
t6042: Add failing testcase for rename/modify/add-source conflict
If there is a cleanly resolvable rename/modify conflict AND there is a new
file introduced on the renamed side of the merge whose name happens to
match that of the source of the rename (but is otherwise unrelated to the
rename), then git fails to cleanly resolve the merge despite the fact that
the new file should not cause any problems.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren [Fri, 12 Aug 2011 05:19:34 +0000 (23:19 -0600)]
t6042: Add a testcase where git deletes an untracked file
Current git will nuke an untracked file during a rename/delete conflict if
(a) there is an untracked file whose name matches the source of a rename
and (b) the merge is done in a certain direction. Add a simple testcase
demonstrating this bug.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jim Meyering [Wed, 8 Jun 2011 20:06:33 +0000 (22:06 +0200)]
fetch: do not leak a refspec
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 1 Jun 2011 21:08:26 +0000 (14:08 -0700)]
Git 1.7.5.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 1 Jun 2011 21:05:22 +0000 (14:05 -0700)]
Merge branch 'jk/maint-config-alias-fix' into maint
* jk/maint-config-alias-fix:
handle_options(): do not miscount how many arguments were used
config: always parse GIT_CONFIG_PARAMETERS during git_config
git_config: don't peek at global config_parameters
config: make environment parsing routines static
Junio C Hamano [Wed, 1 Jun 2011 21:03:07 +0000 (14:03 -0700)]
Merge branch 'jc/fmt-req-fix' into maint
* jc/fmt-req-fix:
userformat_find_requirements(): find requirement for the correct format
Junio C Hamano [Wed, 1 Jun 2011 21:02:52 +0000 (14:02 -0700)]
Merge branch 'jk/maint-docs' into maint
* jk/maint-docs:
docs: fix some antique example output
docs: make sure literal "->" isn't converted to arrow
docs: update status --porcelain format
docs: minor grammar fixes to git-status
Junio C Hamano [Wed, 1 Jun 2011 21:02:45 +0000 (14:02 -0700)]
Merge branch 'jn/doc-remote-helpers' into maint
* jn/doc-remote-helpers:
Documentation: do not misinterpret refspecs as bold text
Junio C Hamano [Wed, 1 Jun 2011 21:02:39 +0000 (14:02 -0700)]
Merge branch 'kk/maint-prefix-in-config-mak' into maint
* kk/maint-prefix-in-config-mak:
config.mak.in: allow "configure --sysconfdir=/else/where"
Jim Meyering [Fri, 29 Apr 2011 09:42:41 +0000 (11:42 +0200)]
diffcore-rename.c: avoid set-but-not-used warning
Since
9d8a5a5 (diffcore-rename: refactor "too many candidates" logic,
2011-01-06), diffcore_rename() initializes num_src but does not use it
anymore. "-Wunused-but-set-variable" in gcc-4.6 complains about this.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 31 May 2011 19:06:40 +0000 (12:06 -0700)]
Start 1.7.5.4 draft release notes
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 31 May 2011 19:02:04 +0000 (12:02 -0700)]
Merge branch 'tr/add-i-no-escape' into maint
* tr/add-i-no-escape:
add -i: ignore terminal escape sequences
Junio C Hamano [Tue, 31 May 2011 19:01:06 +0000 (12:01 -0700)]
Merge branch 'vh/config-interactive-singlekey-doc' into maint
* vh/config-interactive-singlekey-doc:
git-reset.txt: better docs for '--patch'
git-checkout.txt: better docs for '--patch'
git-stash.txt: better docs for '--patch'
git-add.txt: document 'interactive.singlekey'
config.txt: 'interactive.singlekey; is used by...
Junio C Hamano [Tue, 31 May 2011 19:00:43 +0000 (12:00 -0700)]
Merge branch 'ml/test-readme' into maint
* ml/test-readme:
t/README: unify documentation of test function args
Junio C Hamano [Tue, 31 May 2011 19:00:27 +0000 (12:00 -0700)]
Merge branch 'ab/i18n-fixup' into maint
* ab/i18n-fixup: (24 commits)
i18n: use test_i18n{cmp,grep} in t7600, t7607, t7611 and t7811
i18n: use test_i18n{grep,cmp} in t7508
i18n: use test_i18ngrep in t7506
i18n: use test_i18ngrep and test_i18ncmp in t7502
i18n: use test_i18ngrep in t7501
i18n: use test_i18ncmp in t7500
i18n: use test_i18ngrep in t7201
i18n: use test_i18ncmp and test_i18ngrep in t7102 and t7110
i18n: use test_i18ncmp and test_i18ngrep in t5541, t6040, t6120, t7004, t7012 and t7060
i18n: use test_i18ncmp and test_i18ngrep in t3700, t4001 and t4014
i18n: use test_i18ncmp and test_i18ngrep in t3203, t3501 and t3507
i18n: use test_i18ngrep in t2020, t2204, t3030, and t3200
i18n: use test_i18ngrep in lib-httpd and t2019
i18n: do not overuse C_LOCALE_OUTPUT (grep)
i18n: use test_i18ncmp in t1200 and t2200
i18n: .git file is not a human readable message (t5601)
i18n: do not overuse C_LOCALE_OUTPUT
i18n: mark init-db messages for translation
i18n: mark checkout plural warning for translation
i18n: mark checkout --detach messages for translation
...
Junio C Hamano [Tue, 31 May 2011 19:00:02 +0000 (12:00 -0700)]
Merge branch 'jc/rename-degrade-cc-to-c' into maint
* jc/rename-degrade-cc-to-c:
diffcore-rename: fall back to -C when -C -C busts the rename limit
diffcore-rename: record filepair for rename src
diffcore-rename: refactor "too many candidates" logic
builtin/diff.c: remove duplicated call to diff_result_code()
Junio C Hamano [Tue, 31 May 2011 18:59:39 +0000 (11:59 -0700)]
Merge branch 'rr/doc-content-type' into maint
* rr/doc-content-type:
Documentation: Allow custom diff tools to be specified in 'diff.tool'
Documentation: Add diff.<driver>.* to config
Documentation: Move diff.<driver>.* from config.txt to diff-config.txt
Documentation: Add filter.<driver>.* to config
Jonathan Nieder [Mon, 30 May 2011 15:52:56 +0000 (10:52 -0500)]
Documentation: do not misinterpret refspecs as bold text
In v1.7.3.3~2 (Documentation: do not misinterpret pull refspec as bold
text, 2010-12-03) many uses of asterisks in expressions like
"refs/heads/*:refs/svn/origin/branches/*" were escaped as {asterisk}
to avoid being treated as delimiters for bold text, but these two were
missed.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 30 May 2011 07:09:41 +0000 (00:09 -0700)]
Merge branch 'jm/maint-misc-fix' into maint
* jm/maint-misc-fix:
read_gitfile_gently: use ssize_t to hold read result
remove tests of always-false condition
rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
Junio C Hamano [Mon, 30 May 2011 07:09:36 +0000 (00:09 -0700)]
Merge branch 'bc/maint-submodule-fix-parked' into maint
* bc/maint-submodule-fix-parked:
git-submodule.sh: separate parens by a space to avoid confusing some shells
Junio C Hamano [Mon, 30 May 2011 07:03:52 +0000 (00:03 -0700)]
Merge branch 'bc/maint-api-doc-parked' into maint
* bc/maint-api-doc-parked:
Documentation/technical/api-diff.txt: correct name of diff_unmerge()
Junio C Hamano [Mon, 30 May 2011 02:08:51 +0000 (19:08 -0700)]
Merge branch 'jn/run-command-error-failure' into maint
* jn/run-command-error-failure:
run-command: handle short writes and EINTR in die_child
tests: check error message from run_command
Junio C Hamano [Thu, 5 May 2011 01:50:45 +0000 (18:50 -0700)]
config.mak.in: allow "configure --sysconfdir=/else/where"
We do allow vanilla Makefile users to say make sysconfdir=/else/where
and config.mak can also be tweaked manually for the same effect. Give
the same configurablity to ./configure users as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Fri, 27 May 2011 02:33:15 +0000 (22:33 -0400)]
docs: fix some antique example output
These diff-index and diff-tree sample outputs date back to
the first month of git's existence. The output format has
changed slightly since then, so let's have it match the
current output.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Fri, 27 May 2011 02:32:41 +0000 (22:32 -0400)]
docs: make sure literal "->" isn't converted to arrow
Recent versions of asciidoc will treat "->" as a
single-glyph arrow symbol, unless it is inside a literal
code block. This is a problem if we are discussing literal
output and want to show the ASCII characters.
Our usage falls into three categories:
1. Inside a code block. These can be left as-is.
2. Discussing literal output or code, but inside a
paragraph. This patch escapes these as "\->".
3. Using the arrow as a symbolic element, such as "use the
Edit->Account Settings menu". In this case, the
arrow symbol is preferable, so we leave it as-is.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Fri, 27 May 2011 02:31:51 +0000 (22:31 -0400)]
docs: update status --porcelain format
The --porcelain format was originally identical to the
--short format, but designed to be stable as the short
format changed. Since this was written, the short format
picked up a few incompatible niceties, but this description
was never changed.
Let's mention the differences. While we're at it, let's add
some sub-section headings to make the "output" section a
little easier to navigate.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Fri, 27 May 2011 02:31:11 +0000 (22:31 -0400)]
docs: minor grammar fixes to git-status
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Brandon Casey [Thu, 26 May 2011 20:52:04 +0000 (13:52 -0700)]
git-submodule.sh: separate parens by a space to avoid confusing some shells
Some shells interpret '(( ))' according to the rules for arithmetic
expansion. This may not follow POSIX, but is prevalent in commonly used
shells. Bash does not have a problem with this particular instance of
'((', likely because it is not followed by a '))', but the public domain
ksh does, and so does ksh on IRIX 6.5.
So, add a space between the parenthesis to avoid confusing these shells.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Brandon Casey [Thu, 26 May 2011 20:46:56 +0000 (13:46 -0700)]
Documentation/technical/api-diff.txt: correct name of diff_unmerge()
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Thu, 26 May 2011 16:28:44 +0000 (12:28 -0400)]
read_gitfile_gently: use ssize_t to hold read result
Otherwise, a negative error return becomes a very large read
value. We catch this in practice because we compare the
expected and actual numbers of bytes (and you are not likely
to be reading (size_t)-1 bytes), but this makes the
correctness a little more obvious.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jim Meyering [Thu, 26 May 2011 13:58:16 +0000 (15:58 +0200)]
remove tests of always-false condition
* fsck.c (fsck_error_function): Don't test obj->sha1 == 0.
It can never be true, since that sha1 member is an array.
* transport.c (set_upstreams): Likewise for ref->new_sha1.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jim Meyering [Thu, 26 May 2011 13:54:18 +0000 (15:54 +0200)]
rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
If we reach EOF after the SHA1-then-TAB, yet before the NUL that
terminates each file name, we would fill the file name buffer with \255
bytes resulting from the repeatedly-failing fgetc (returns EOF/-1) and
ultimately complain about "filename too long", because no NUL was
encountered.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 26 May 2011 16:45:29 +0000 (09:45 -0700)]
Git 1.7.5.3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 26 May 2011 17:29:24 +0000 (10:29 -0700)]
Merge branch 'maint-1.7.4' into maint
* maint-1.7.4:
Junio C Hamano [Thu, 26 May 2011 17:28:10 +0000 (10:28 -0700)]
Merge branch 'jk/git-connection-deadlock-fix' into maint-1.7.4
* jk/git-connection-deadlock-fix:
test core.gitproxy configuration
send-pack: avoid deadlock on git:// push with failed pack-objects
connect: let callers know if connection is a socket
connect: treat generic proxy processes like ssh processes
Conflicts:
connect.c
Junio C Hamano [Thu, 26 May 2011 17:27:55 +0000 (10:27 -0700)]
Merge branch 'js/maint-send-pack-stateless-rpc-deadlock-fix' into maint-1.7.4
* js/maint-send-pack-stateless-rpc-deadlock-fix:
sideband_demux(): fix decl-after-stmt
send-pack: unbreak push over stateless rpc
send-pack: avoid deadlock when pack-object dies early
Junio C Hamano [Thu, 26 May 2011 17:27:29 +0000 (10:27 -0700)]
Merge branch 'jk/maint-upload-pack-shallow' into maint-1.7.4
* jk/maint-upload-pack-shallow:
upload-pack: start pack-objects before async rev-list
Junio C Hamano [Thu, 26 May 2011 16:43:00 +0000 (09:43 -0700)]
Merge branch 'jm/maint-diff-words-with-sbe' into maint
* jm/maint-diff-words-with-sbe:
do not read beyond end of malloc'd buffer
Junio C Hamano [Thu, 26 May 2011 16:42:12 +0000 (09:42 -0700)]
Merge branch 'kk/maint-prefix-in-config-mak' into maint
* kk/maint-prefix-in-config-mak:
Honor $(prefix) set in config.mak* when defining ETC_GIT*
Revert "Honor $(prefix) set in config.mak* when defining ETC_GIT* and sysconfdir"
Honor $(prefix) set in config.mak* when defining ETC_GIT* and sysconfdir
Junio C Hamano [Thu, 26 May 2011 16:41:11 +0000 (09:41 -0700)]
Merge branch 'mg/diff-uiconfig-doc' into maint
* mg/diff-uiconfig-doc:
config.txt,diff-options.txt: porcelain vs. plumbing for color.diff
Junio C Hamano [Thu, 26 May 2011 16:40:50 +0000 (09:40 -0700)]
Merge branch 'ft/gitweb-tar-with-gzip-n' into maint
* ft/gitweb-tar-with-gzip-n:
gitweb: supply '-n' to gzip for identical output
Junio C Hamano [Thu, 26 May 2011 16:39:40 +0000 (09:39 -0700)]
Merge branch 'ss/doc-svn' into maint
* ss/doc-svn:
remove noise and inaccuracies from git-svn docs
Junio C Hamano [Thu, 26 May 2011 16:39:33 +0000 (09:39 -0700)]
Merge branch 'jn/format-patch-doc' into maint
* jn/format-patch-doc:
Documentation/format-patch: suggest Toggle Word Wrap add-on for Thunderbird
Documentation: publicize hints for sending patches with GMail
Documentation: publicize KMail hints for sending patches inline
Documentation: hints for sending patches inline with Thunderbird
Documentation: explain how to check for patch corruption
Junio C Hamano [Thu, 26 May 2011 16:38:44 +0000 (09:38 -0700)]
Merge branch 'jc/maint-pathspec-stdin-and-cmdline' into maint
* jc/maint-pathspec-stdin-and-cmdline:
setup_revisions(): take pathspec from command line and --stdin correctly
Junio C Hamano [Thu, 26 May 2011 16:37:41 +0000 (09:37 -0700)]
Merge branch 'jk/cherry-pick-root-with-resolve' into maint
* jk/cherry-pick-root-with-resolve:
t3503: test cherry picking and reverting root commits
revert: allow reverting a root commit
cherry-pick: handle root commits with external strategies
Junio C Hamano [Thu, 26 May 2011 16:37:04 +0000 (09:37 -0700)]
Merge branch 'rg/copy-gecos-username' into maint
* rg/copy-gecos-username:
copy_gecos: fix not adding nlen to len when processing "&"
Junio C Hamano [Thu, 26 May 2011 16:36:33 +0000 (09:36 -0700)]
Merge branch 'fc/completion-zsh' into maint
* fc/completion-zsh:
git-completion: fix regression in zsh support
Junio C Hamano [Thu, 26 May 2011 16:33:25 +0000 (09:33 -0700)]
Merge branch 'jk/git-connection-deadlock-fix' into maint
* jk/git-connection-deadlock-fix:
test core.gitproxy configuration
send-pack: avoid deadlock on git:// push with failed pack-objects
connect: let callers know if connection is a socket
connect: treat generic proxy processes like ssh processes
Conflicts:
connect.c
Junio C Hamano [Thu, 26 May 2011 16:32:14 +0000 (09:32 -0700)]
Merge branch 'js/maint-send-pack-stateless-rpc-deadlock-fix' into maint
* js/maint-send-pack-stateless-rpc-deadlock-fix:
sideband_demux(): fix decl-after-stmt
send-pack: unbreak push over stateless rpc
send-pack: avoid deadlock when pack-object dies early
Junio C Hamano [Thu, 26 May 2011 15:52:11 +0000 (08:52 -0700)]
Merge branch 'svn-fe-maint' of git://repo.or.cz/git/jrn into maint
* 'svn-fe-maint' of git://repo.or.cz/git/jrn:
Revert "t0081 (line-buffer): add buffering tests"
Junio C Hamano [Wed, 25 May 2011 19:23:44 +0000 (12:23 -0700)]
userformat_find_requirements(): find requirement for the correct format
This function was introduced in
5b16360 (pretty: Initialize notes if %N is
used, 2010-04-13) to check what kind of information the "log --format=..."
user format string wants. The function can be passed a NULL instead of a
format string to ask it to check user_format variable kept by an earlier
call to save_user_format().
But it unconditionally checked user_format and not the string it was
given. The only caller introduced by the change passes NULL, which
kept the bug unnoticed, until a new GCC noticed that there is an
assignment to fmt that is never used.
Noticed-by: Chris Wilson's compiler
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Jeff King <peff@peff.net>
Nguyen Thai Ngoc Duy [Tue, 24 May 2011 16:40:32 +0000 (23:40 +0700)]
init/clone: remove short option -L and document --separate-git-dir
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 24 May 2011 22:50:35 +0000 (18:50 -0400)]
handle_options(): do not miscount how many arguments were used
The handle_options() function advances the base of the argument array and
returns the number of arguments it used. The caller in handle_alias()
wants to reallocate the argv array it passes to this function, and
attempts to do so by subtracting the returned value to compensate for the
change handle_options() makes to the new_argv.
But handle_options() did not correctly count when "-c <config=value>" is
given, causing a wrong pointer to be passed to realloc().
Fix it by saving the original argv at the beginning of handle_options(),
and return the difference between the final value of argv, which will
relieve the places that move the array pointer from the additional burden
of keeping track of "handled" counter.
Noticed-by: Kazuki Tsujimoto
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>