summaryrefslogtreecommitdiff
path: root/merge-recursive.c
AgeCommit message (Collapse)AuthorFilesLines
2017-06-30merge-recursive: use DIFF_XDL_SET macroLibravatar Stefan Beller1-3/+3
Instead of implementing this on our own, just use a convenience macro. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27Merge branch 'mm/merge-rename-delete-message'Libravatar Junio C Hamano1-54/+63
When "git merge" detects a path that is renamed in one history while the other history deleted (or modified) it, it now reports both paths to help the user understand what is going on in the two histories being merged. * mm/merge-rename-delete-message: merge-recursive: make "CONFLICT (rename/delete)" message show both paths
2017-01-30use SWAP macroLibravatar René Scharfe1-4/+1
Apply the semantic patch swap.cocci to convert hand-rolled swaps to use the macro SWAP. The resulting code is shorter and easier to read, the object code is effectively unchanged. The patch for object.c had to be hand-edited in order to preserve the comment before the change; Coccinelle tried to eat it for some reason. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-30merge-recursive: make "CONFLICT (rename/delete)" message show both pathsLibravatar Matt McCutchen1-54/+63
The current message printed by "git merge-recursive" for a rename/delete conflict is like this: CONFLICT (rename/delete): new-path deleted in HEAD and renamed in other-branch. Version other-branch of new-path left in tree. To be more helpful, the message should show both paths of the rename and state that the deletion occurred at the old path, not the new path. So change the message to the following format: CONFLICT (rename/delete): old-path deleted in HEAD and renamed to new-path in other-branch. Version other-branch of new-path left in tree. Since this doubles the number of cases in handle_change_delete (modify vs. rename), refactor the code to halve the number of cases again by merging the cases where o->branch1 has the change and o->branch2 has the delete with the cases that are the other way around. Also add a simple test of the new conflict message. Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17Merge branch 'nd/qsort-in-merge-recursive' into maintLibravatar Junio C Hamano1-9/+7
Code simplification. * nd/qsort-in-merge-recursive: merge-recursive.c: use string_list_sort instead of qsort
2017-01-17Merge branch 'jc/renormalize-merge-kill-safer-crlf' into maintLibravatar Junio C Hamano1-0/+2
Fix a corner case in merge-recursive regression that crept in during 2.10 development cycle. * jc/renormalize-merge-kill-safer-crlf: convert: git cherry-pick -Xrenormalize did not work merge-recursive: handle NULL in add_cacheinfo() correctly cherry-pick: demonstrate a segmentation fault
2016-12-19Merge branch 'jc/lock-report-on-error'Libravatar Junio C Hamano1-1/+1
Git 2.11 had a minor regression in "merge --ff-only" that competed with another process that simultanously attempted to update the index. We used to explain what went wrong with an error message, but the new code silently failed. The error message has been resurrected. * jc/lock-report-on-error: lockfile: LOCK_REPORT_ON_ERROR hold_locked_index(): align error handling with hold_lockfile_for_update() wt-status: implement opportunisitc index update correctly
2016-12-19Merge branch 'jc/renormalize-merge-kill-safer-crlf'Libravatar Junio C Hamano1-0/+2
Fix a corner case in merge-recursive regression that crept in during 2.10 development cycle. * jc/renormalize-merge-kill-safer-crlf: convert: git cherry-pick -Xrenormalize did not work merge-recursive: handle NULL in add_cacheinfo() correctly cherry-pick: demonstrate a segmentation fault
2016-12-16Merge branch 'nd/qsort-in-merge-recursive'Libravatar Junio C Hamano1-9/+7
Code simplification. * nd/qsort-in-merge-recursive: merge-recursive.c: use string_list_sort instead of qsort
2016-12-07hold_locked_index(): align error handling with hold_lockfile_for_update()Libravatar Junio C Hamano1-1/+1
Callers of the hold_locked_index() function pass 0 when they want to prepare to write a new version of the index file without wishing to die or emit an error message when the request fails (e.g. somebody else already held the lock), and pass 1 when they want the call to die upon failure. This option is called LOCK_DIE_ON_ERROR by the underlying lockfile API, and the hold_locked_index() function translates the paramter to LOCK_DIE_ON_ERROR when calling the hold_lock_file_for_update(). Replace these hardcoded '1' with LOCK_DIE_ON_ERROR and stop translating. Callers other than the ones that are replaced with this change pass '0' to the function; no behaviour change is intended with this patch. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- Among the callers of hold_locked_index() that passes 0: - diff.c::refresh_index_quietly() at the end of "git diff" is an opportunistic update; it leaks the lockfile structure but it is just before the program exits and nobody should care. - builtin/describe.c::cmd_describe(), builtin/commit.c::cmd_status(), sequencer.c::read_and_refresh_cache() are all opportunistic updates and they are OK. - builtin/update-index.c::cmd_update_index() takes a lock upfront but we may end up not needing to update the index (i.e. the entries may be fully up-to-date), in which case we do not need to issue an error upon failure to acquire the lock. We do diagnose and die if we indeed need to update, so it is OK. - wt-status.c::require_clean_work_tree() IS BUGGY. It asks silence, does not check the returned value. Compare with callsites like cmd_describe() and cmd_status() to notice that it is wrong to call update_index_if_able() unconditionally.
2016-11-28merge-recursive.c: use string_list_sort instead of qsortLibravatar Nguyễn Thái Ngọc Duy1-9/+7
Merge-recursive sorts a string list using a raw qsort(), where it feeds the "items" from one struct but the "nr" and size fields from another struct. This isn't a bug because one list is a copy of the other, but it's unnecessarily confusing (and also caused our recent QSORT() cleanups via coccinelle to miss this call site). Let's use string_list_sort() instead, which is more concise and harder to get wrong. Note that we need to adjust our comparison function, which gets fed only the strings now, not the string_list_items. That's OK because we don't use the "util" field as part of our sort. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-28merge-recursive: handle NULL in add_cacheinfo() correctlyLibravatar Johannes Schindelin1-0/+2
1335d76e45 ("merge: avoid "safer crlf" during recording of merge results", 2016-07-08) tried to split make_cache_entry() call made with CE_MATCH_REFRESH into a call to make_cache_entry() without one, followed by a call to add_cache_entry(), refresh_cache() and another add_cache_entry() as needed. However the conversion was botched in that it forgot that refresh_cache() can return NULL, which was handled correctly in make_cache_entry() but in the updated code. This fixes https://github.com/git-for-windows/git/issues/952 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-17submodules: allow empty working-tree dirs in merge/cherry-pickLibravatar David Turner1-6/+15
When a submodule is being merged or cherry-picked into a working tree that already contains a corresponding empty directory, do not record a conflict. One situation where this bug appears is: - Commit 1 adds a submodule - Commit 2 removes that submodule and re-adds it into a subdirectory (sub1 to sub1/sub1). - Commit 3 adds an unrelated file. Now the user checks out commit 1 (first deinitializing the submodule), and attempts to cherry-pick commit 3. Previously, this would fail, because the incoming submodule sub1/sub1 would falsely conflict with the empty sub1 directory. This patch ignores the empty sub1 directory, fixing the bug. We only ignore the empty directory if the object being emplaced is a submodule, which expects an empty directory. Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-17Merge branch 'rs/cocci'Libravatar Junio C Hamano1-3/+3
Code cleanup. * rs/cocci: use strbuf_add_unique_abbrev() for adding short hashes, part 3 remove unnecessary NULL check before free(3)
2016-10-10use strbuf_add_unique_abbrev() for adding short hashes, part 3Libravatar René Scharfe1-3/+3
Call strbuf_add_unique_abbrev() to add abbreviated hashes to strbufs instead of taking detours through find_unique_abbrev() and its static buffer. This is shorter in most cases and a bit more efficient. The changes here are not easily handled by a semantic patch because they involve removing temporary variables and deconstructing format strings for strbuf_addf(). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26Merge branch 'rs/cocci'Libravatar Junio C Hamano1-1/+1
Code cleanup. * rs/cocci: use strbuf_addstr() for adding constant strings to a strbuf, part 2 add coccicheck make target contrib/coccinelle: fix semantic patch for oid_to_hex_r()
2016-09-15use strbuf_addstr() for adding constant strings to a strbuf, part 2Libravatar René Scharfe1-1/+1
Replace uses of strbuf_addf() for adding strings with more lightweight strbuf_addstr() calls. This makes the intent clearer and avoids potential issues with printf format specifiers. 02962d36845b89145cd69f8bc65e015d78ae3434 already converted six cases, this patch covers eleven more. A semantic patch for Coccinelle is included for easier checking for new cases that might be introduced in the future. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07Convert read_mmblob to take struct object_id.Libravatar brian m. carlson1-3/+3
Since all of its callers have been updated, convert read_mmblob to take a pointer to struct object_id. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07cache: convert struct cache_entry to use struct object_idLibravatar brian m. carlson1-1/+1
Convert struct cache_entry to use struct object_id by applying the following semantic patch and the object_id transforms from contrib, plus the actual change to the struct: @@ struct cache_entry E1; @@ - E1.sha1 + E1.oid.hash @@ struct cache_entry *E1; @@ - E1->sha1 + E1->oid.hash Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-19Merge branch 'rs/pull-signed-tag'Libravatar Junio C Hamano1-4/+1
When "git merge-recursive" works on history with many criss-cross merges in "verbose" mode, the names the command assigns to the virtual merge bases could have overwritten each other by unintended reuse of the same piece of memory. * rs/pull-signed-tag: commit: use FLEX_ARRAY in struct merge_remote_desc merge-recursive: fix verbose output for multiple base trees commit: factor out set_merge_remote_desc() commit: use xstrdup() in get_merge_parent()
2016-08-13merge-recursive: fix verbose output for multiple base treesLibravatar René Scharfe1-4/+1
One of the indirect callers of make_virtual_commit() passes the result of oid_to_hex() as the name, i.e. a pointer to a static buffer. Since the function uses that string pointer directly in building a struct merge_remote_desc, multiple entries can end up sharing the same name inadvertently. Fix that by calling set_merge_remote_desc(), which creates a copy of the string, instead of building the struct by hand. Signed-off-by: Rene Scharfe <l.s.r@web.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-12Merge branch 'rs/merge-recursive-string-list-init'Libravatar Junio C Hamano1-2/+1
A small code clean-up. * rs/merge-recursive-string-list-init: merge-recursive: use STRING_LIST_INIT_NODUP
2016-08-05merge-recursive: use STRING_LIST_INIT_NODUPLibravatar René Scharfe1-2/+1
Initialize a string_list right when it's defined. That's shorter, saves a function call and makes it more obvious that we're using the NODUP variant here. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01merge-recursive: flush output buffer even when erroring outLibravatar Johannes Schindelin1-1/+3
Ever since 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we had a problem: When the merge failed in a fatal way, all regular output was swallowed because we called die() and did not get a chance to drain the output buffers. To fix this, several modifications were necessary: - we needed to stop die()ing, to give callers a chance to do something when an error occurred (in this case, flush the output buffers), - we needed to delay printing the error message so that the caller can print the buffered output before that, and - we needed to make sure that the output buffers are flushed even when the return value indicates an error. The first two changes were introduced through earlier commits in this patch series, and this commit addresses the third one. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01merge_trees(): ensure that the callers release output bufferLibravatar Johannes Schindelin1-0/+2
The recursive merge machinery accumulates its output in an output buffer, to be flushed at the end of merge_recursive(). At this point, we forgot to release the output buffer. When calling merge_trees() (i.e. the non-recursive part of the recursive merge) directly, the output buffer is never flushed because the caller may be merge_recursive() which wants to flush the output itself. For the same reason, merge_trees() cannot release the output buffer: it may still be needed. Forgetting to release the output buffer did not matter much when running git-checkout, or git-merge-recursive, because we exited after the operation anyway. Ever since cherry-pick learned to pick a commit range, however, this memory leak had the potential of becoming a problem. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01merge-recursive: offer an option to retain the output in 'obuf'Libravatar Johannes Schindelin1-4/+13
Since 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we already accumulate the output in a buffer. The idea was to avoid interfering with the progress output that goes to stderr, which is unbuffered, when we write to stdout, which is buffered. We extend that buffering to allow the caller to handle the output (possibly suppressing it). This will help us when extending the sequencer to do rebase -i's brunt work: it does not want the picks to print anything by default but instead determine itself whether to print the output or not. Note that we also redirect the error messages into the output buffer when the caller asked not to flush the output buffer, for two reasons: 1) to retain the correct output order, and 2) to allow the caller to suppress *all* output. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01merge-recursive: write the commit title in one goLibravatar Johannes Schindelin1-8/+9
In 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we changed the code such that it prints the output in one go, to avoid interfering with the progress output. Let's make sure that the same holds true when outputting the commit title: previously, we used several printf() statements to stdout and assumed that stdout's buffer is large enough to hold the entire commit title. Apart from making that speculation unnecessary, we change the code to add the message to the output buffer before flushing for another reason: the next commit will introduce a new level of output buffering, where the caller can request the output not to be flushed, but to be retained for further processing. This latter feature will be needed when teaching the sequencer to do rebase -i's brunt work: it wants to control the output of the cherry-picks (i.e. recursive merges). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01merge-recursive: flush output buffer before printing error messagesLibravatar Johannes Schindelin1-48/+68
The data structure passed to the recursive merge machinery has a feature where the caller can ask for the output to be buffered into a strbuf, by setting the field 'buffer_output'. Previously, we died without flushing, losing accumulated output. With this patch, we show the output first, and only then print the error message. Currently, the only user of that buffering is merge_recursive() itself, to avoid the progress output to interfere. In the next patches, we will introduce a new buffer_output mode that forces merge_recursive() to retain the output buffer for further processing by the caller. If the caller asked for that, we will then also write the error messages into the output buffer. This is necessary to give the caller more control not only how to react in case of errors but also control how/if to display the error messages. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26merge-recursive: switch to returning errors instead of dyingLibravatar Johannes Schindelin1-27/+35
The recursive merge machinery is supposed to be a library function, i.e. it should return an error when it fails. Originally the functions were part of the builtin "merge-recursive", though, where it was simpler to call die() and be done with error handling. The existing callers were already prepared to detect negative return values to indicate errors and to behave as previously: exit with code 128 (which is the same thing that die() does, after printing the message). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26merge-recursive: handle return values indicating errorsLibravatar Johannes Schindelin1-102/+150
We are about to libify the recursive merge machinery, where we only die() in case of a bug or memory contention. To that end, we must heed negative return values as indicating errors. This requires our functions to be careful to pass through error conditions in call chains, and for quite a few functions this means that they have to return values to begin with. The next step will be to convert the places where we currently die() to return negative values (read: -1) instead. Note that we ignore errors reported by make_room_for_path(), consistent with the previous behavior (update_file_flags() used the return value of make_room_for_path() only to indicate an early return, but not a fatal error): if the error is really a fatal error, we will notice later; If not, it was not that serious a problem to begin with. (Witnesses in favor of this reasoning are t4151-am-abort and t7610-mergetool, which would start failing if we stopped on errors reported by make_room_for_path()). Also note: while this patch makes the code slightly less readable in update_file_flags() (we introduce a new "goto free_buf;" instead of an explicit "free(buf); return;"), it is a preparatory change for the next patch where we will convert all of the die() calls in the same function to go through the free_buf return path instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26merge-recursive: allow write_tree_from_memory() to error outLibravatar Johannes Schindelin1-2/+2
It is possible that a tree cannot be written (think: disk full). We will want to give the caller a chance to clean up instead of letting the program die() in such a case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26merge-recursive: avoid returning a wholesale structLibravatar Johannes Schindelin1-50/+56
It is technically allowed, as per C89, for functions' return type to be complete structs (i.e. *not* just pointers to structs). However, it was just an oversight of this developer when converting Python code to C code in 6d297f8 (Status update on merge-recursive in C, 2006-07-08) which introduced such a return type. Besides, by converting this construct to pass in the struct, we can now start returning a value that can indicate errors in future patches. This will help the current effort to libify merge-recursive.c. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26merge_recursive: abort properly upon errorsLibravatar Johannes Schindelin1-5/+12
There are a couple of places where return values never indicated errors before, as we simply died instead of returning. But now negative return values mean that there was an error and we have to abort the operation. Let's do exactly that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26merge-recursive: clarify code in was_tracked()Libravatar Johannes Schindelin1-16/+14
It can be puzzling to see that was_tracked() asks to get an index entry by name, but does not take a negative return value for an answer. The reason we have to do this is that cache_name_pos() only looks for entries in stage 0, even if nobody asked for any stage in particular. Let's rewrite the logic a little bit, to handle the easy case early: if cache_name_pos() returned a non-negative position, we know it is a match, and we do not even have to compare the name again (cache_name_pos() did that for us already). We can say right away: yes, this file was tracked. Only if there was no exact match do we need to look harder for any matching entry in stage 2. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26die(_("BUG")): avoid translating bug messagesLibravatar Johannes Schindelin1-3/+3
While working on the patch series that avoids die()ing in recursive merges, the issue came up that bug reports (i.e. die("BUG: ...") constructs) should never be translated, as the target audience is the Git developer community, not necessarily the current user, and hence a translated message would make it *harder* to address the problem. So let's stop translating the obvious ones. As it is really, really outside the purview of this patch series to see whether there are more die() statements that report bugs and are currently translated, that task is left for another day and patch. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26die("bug"): report bugs consistentlyLibravatar Johannes Schindelin1-8/+7
The vast majority of error messages in Git's source code which report a bug use the convention to prefix the message with "BUG:". As part of cleaning up merge-recursive to stop die()ing except in case of detected bugs, let's just make the remainder of the bug reports consistent with the de facto rule. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-25Merge branch 'jc/renormalize-merge-kill-safer-crlf'Libravatar Junio C Hamano1-4/+13
"git merge" with renormalization did not work well with merge-recursive, due to "safer crlf" conversion kicking in when it shouldn't. * jc/renormalize-merge-kill-safer-crlf: merge: avoid "safer crlf" during recording of merge results convert: unify the "auto" handling of CRLF
2016-07-12merge: avoid "safer crlf" during recording of merge resultsLibravatar Junio C Hamano1-4/+13
When merge_recursive() decides what the correct blob object merge result for a path should be, it uses update_file_flags() helper function to write it out to a working tree file and then calls add_cacheinfo(). The add_cacheinfo() function in turn calls make_cache_entry() to create a new cache entry to replace the higher-stage entries for the path that represents the conflict. The make_cache_entry() function calls refresh_cache_entry() to fill in the cached stat information. To mark a cache entry as up-to-date, the data is re-read from the file in the working tree, and goes through convert_to_git() conversion to be compared with the blob object name the new cache entry records. It is important to note that this happens while the higher-stage entries, which are going to be replaced with the new entry, are still in the index. Unfortunately, the convert_to_git() conversion has a misguided "safer crlf" mechanism baked in, and looks at the existing cache entry for the path to decide how to convert the contents in the working tree file. If our side (i.e. stage#2) records a text blob with CRLF in it, even when the system is configured to record LF in blobs and convert them to CRLF upon checkout (and back to LF upon checkin), the "safer crlf" mechanism stops us doing so. This especially poses a problem during a renormalizing merge, where the merge result for the path is computed by first "normalizing" the blobs involved in the merge by using convert_to_working_tree() followed by convert_to_git() with "safer crlf" disabled. The merge result that is computed correctly and fed to add_cacheinfo() via update_file_flags() does _not_ match what refresh_cache_entry() sees by converting the working tree file via convert_to_git(). We can work this around by not refreshing the new cache entry in make_cache_entry() called by add_cacheinfo(). After add_cacheinfo() adds the new entry, we can call refresh_cache_entry() on that, knowing that addition of this new cache entry would have removed the stale cache entries that had CRLF in stage #2 that were carried over before the renormalizing merge started and will not interfere with the correct recording of the result. The test update was taken from a series by Torsten Bögershausen that attempted to fix this with a different approach. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Torsten Bögershausen <tboegi@web.de>
2016-06-28merge-recursive: convert merge_recursive_generic() to object_idLibravatar brian m. carlson1-7/+7
Convert this function and the git merge-recursive subcommand to use struct object_id. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28merge-recursive: convert leaf functions to use struct object_idLibravatar brian m. carlson1-118/+118
Convert all but two of the static functions in this file to use struct object_id. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28merge-recursive: convert struct merge_file_info to object_idLibravatar brian m. carlson1-19/+20
Convert struct merge_file_info to use struct object_id. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct merge_file_info o; @@ - o.sha + o.oid.hash @@ struct merge_file_info *p; @@ - p->sha + p->oid.hash Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28merge-recursive: convert struct stage_data to use object_idLibravatar brian m. carlson1-20/+18
Convert the anonymous struct within struct stage_data to use struct object_id. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct stage_data o; expression E1; @@ - o.stages[E1].sha + o.stages[E1].oid.hash @@ struct stage_data *p; expression E1; @@ - p->stages[E1].sha + p->stages[E1].oid.hash Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28diff: convert struct diff_filespec to struct object_idLibravatar brian m. carlson1-49/+58
Convert struct diff_filespec's sha1 member to use a struct object_id called "oid" instead. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct diff_filespec o; @@ - o.sha1 + o.oid.hash @@ struct diff_filespec *p; @@ - p->sha1 + p->oid.hash Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-06Merge branch 'bc/object-id'Libravatar Junio C Hamano1-2/+2
Move from unsigned char[20] to struct object_id continues. * bc/object-id: match-trees: convert several leaf functions to use struct object_id tree-walk: convert tree_entry_extract() to use struct object_id struct name_entry: use struct object_id instead of unsigned char sha1[20] match-trees: convert shift_tree() and shift_tree_by() to use object_id test-match-trees: convert to use struct object_id sha1-name: introduce a get_oid() function
2016-04-19match-trees: convert shift_tree() and shift_tree_by() to use object_idLibravatar brian m. carlson1-2/+2
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-12merge-recursive: do not check working copy when creating a virtual merge baseLibravatar Elijah Newren1-3/+3
There were a few cases in merge-recursive that could result in a check for the presence of files in the working copy while trying to create a virtual merge base. These were rare and innocuous, but somewhat illogical. The two cases were: * When there was naming conflicts (e.g. a D/F conflict) and we had to pick a new unique name for a file. Since the new name is somewhat arbitrary, it didn't matter that we consulted the working copy to avoid picking a filename it has, but since the virtual merge base is never checked out, it's a waste of time and slightly odd to do so. * When two different files get renamed to the same name (on opposite sides of the merge), we needed to delete the original filenames from the cache and possibly also the working directory. The caller's check for determining whether to delete from the working directory was a call to would_lose_untracked(). It turns out this didn't matter because remove_file() had logic to avoid modifying the working directory when creating a virtual merge base, but there is no reason for the caller to check the working directory in such circumstances. It's a waste of time, if not also a bit weird. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-12merge-recursive: remove duplicate codeLibravatar Elijah Newren1-2/+0
In commit 51931bf (merge-recursive: Improve handling of rename target vs. directory addition, 2011-08-11), I apparently added two lines of code that were immediately duplicated a few lines later. No idea why, other than it seems pretty clear this was a mistake: there is no need to remove the same file twice; removing it once is sufficient...especially since the intervening line was working with a different file entirely. Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-24merge-recursive: find-renames resets thresholdLibravatar Felipe Gonçalves Assis1-1/+3
Make the find-renames option follow the behaviour in git-diff, where it resets the threshold when none is given. So, for instance, "--find-renames=25 --find-renames" should result in the default threshold (50%) instead of 25%. Signed-off-by: Felipe Gonçalves Assis <felipegassis@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17merge-recursive: more consistent interfaceLibravatar Felipe Gonçalves Assis1-1/+4
Add strategy option find-renames, following git-diff interface. This makes the option rename-threshold redundant. Signed-off-by: Felipe Gonçalves Assis <felipegassis@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17merge-recursive: option to disable renamesLibravatar Felipe Gonçalves Assis1-0/+7
The recursive strategy turns on rename detection by default. Add a strategy option to disable rename detection even for exact renames. Signed-off-by: Felipe Gonçalves Assis <felipegassis@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>