summaryrefslogtreecommitdiff
path: root/git-merge-one-file.sh
Commit message (Collapse)AuthorAgeFilesLines
* merge-one-file: compute empty blob object IDbrian m. carlson2018-05-021-1/+1
| | | | | | | | | This script hard-codes the object ID of the empty blob. To avoid any problems when changing hashes, compute this value by calling git hash-object. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* scripts: use "git foo" not "git-foo"mf/no-dashed-subcommandsMichael Forney2017-08-071-4/+4
| | | | | | | | | We want to make sure that people who copy & paste code would see fewer instances of "git-foo". The use of these dashed forms have been discouraged since v1.6.0 days. Signed-off-by: Michael Forney <mforney@mforney.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jk/no-diff-emit-common'Junio C Hamano2016-02-261-2/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | "git merge-tree" used to mishandle "both sides added" conflict with its own "create a fake ancestor file that has the common parts of what both sides have added and do a 3-way merge" logic; this has been updated to use the usual "3-way merge with an empty blob as the fake common ancestor file" approach used in the rest of the system. * jk/no-diff-emit-common: xdiff: drop XDL_EMIT_COMMON merge-tree: drop generate_common strategy merge-one-file: use empty blob for add/add base
| * merge-one-file: use empty blob for add/add baseJeff King2016-02-221-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we see an add/add conflict on a file, we generate the conflicted content by doing a 3-way merge with a "virtual" base consisting of the common lines of the two sides. This strategy dates back to cb93c19 (merge-one-file: use common as base, instead of emptiness., 2005-11-09). Back then, the next step was to call rcs merge to generate the 3-way conflicts. Using the virtual base produced much better results, as rcs merge does not attempt to minimize the hunks. As a result, you'd get a conflict with the entirety of the files on either side. Since then, though, we've switched to using git-merge-file, which uses xdiff's "zealous" merge. This will find the minimal hunks even with just the simple, empty base. Let's switch to using that empty base. It's simpler, more efficient, and reduces our dependencies (we no longer need a working diff binary). It's also how the merge-recursive strategy handles this same case. We can almost get rid of git-sh-setup's create_virtual_base, but we don't here, for two reasons: 1. The functions in git-sh-setup are part of our public interface, so it's possible somebody is depending on it. We'd at least need to deprecate it first. 2. It's also used by mergetool's p4merge driver. It's unknown whether its 3-way merge is as capable as git's; if not, then it is benefiting from the function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | merge: detect delete/modechange conflictjk/delete-modechange-conflictJeff King2015-10-261-0/+8
|/ | | | | | | | | | | | | | | | | | | If one side deletes a file and the other changes its content, we notice and report a conflict. However, if instead of changing the content, we change only the mode, the merge does not notice (and the mode change is silently dropped). The trivial index merge notices the problem and correctly leaves the conflict in the index, but both merge-recursive and merge-one-file will silently resolve this in favor of the deletion. In many cases that is a sane resolution, but we should be punting to the user whenever there is any question. So let's detect and treat this as a conflict (in both strategies). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'kb/p4merge'Junio C Hamano2013-03-261-33/+28
|\ | | | | | | | | | | | | | | | | | | | | | | | | Adjust the order mergetools feeds the files to the p4merge backend to match the p4 convention. * kb/p4merge: merge-one-file: force content conflict for "both sides added" case git-merge-one-file: send "ERROR:" messages to stderr git-merge-one-file: style cleanup merge-one-file: remove stale comment mergetools/p4merge: create a base if none available mergetools/p4merge: swap LOCAL and REMOTE
| * merge-one-file: force content conflict for "both sides added" caseJunio C Hamano2013-03-251-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically, we tried to be lenient to "both sides added, slightly differently" case and as long as the files can be merged using a made-up common ancestor cleanly, since f7d24bbefb06 (merge with /dev/null as base, instead of punting O==empty case, 2005-11-07). This was later further refined to use a better made-up common file with fd66dbf5297a (merge-one-file: use empty- or common-base condintionally in two-stage merge., 2005-11-10), but the spirit has been the same. But the original fix in f7d24bbefb06 to avoid punting on "both sides added" case had a code to unconditionally error out the merge. When this triggers, even though the content-level merge can be done cleanly, we end up not saying "content conflict" in the message, but still issue the error message, showing "ERROR: in <pathname>". Move that "always fail for add/add conflict" logic a bit higher to fix this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git-merge-one-file: send "ERROR:" messages to stderrKevin Bracey2013-03-251-7/+7
| | | | | | | | | | Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git-merge-one-file: style cleanupKevin Bracey2013-03-251-9/+17
| | | | | | | | | | | | | | Update style to match Documentation/CodingGuidelines. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-one-file: remove stale commentJunio C Hamano2013-03-251-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "funny filename" comment was from b539c5e8fbd3 (git-merge-one: new merge world order., 2005-12-07) where the removed code just before that new comment ended with: merge "$4" "$orig" "$src2" (yes, we used to use "merge" program from the RCS suite). The comment refers to one of the bad side effect the old code used to have and warns against such a practice, i.e. it was talking about the code that no longer existed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * mergetools/p4merge: create a base if none availableKevin Bracey2013-03-131-13/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, with no base, Git gave P4Merge $LOCAL as a dummy base: p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED" Commit 0a0ec7bd changed this to: p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED" to avoid the problem of being unable to save in some circumstances with similar inputs. Unfortunately this approach produces much worse results on differing inputs. P4Merge really regards the blank file as the base, and once you have just a couple of differences between the two branches you end up with one a massive full-file conflict. The 3-way diff is not readable, and you have to invoke "difftool MERGE_HEAD HEAD" manually to get a useful view. The original approach appears to have invoked special 2-way merge behaviour in P4Merge that occurs only if the base filename is "" or equal to the left input. You get a good visual comparison, and it does not auto-resolve differences. (Normally if one branch matched the base, it would autoresolve to the other branch). But there appears to be no way of getting this 2-way behaviour and being able to reliably save. Having base==left appears to be triggering other assumptions. There are tricks the user can use to force the save icon on, but it's not intuitive. So we now follow a suggestion given in the original patch's discussion: generate a virtual base, consisting of the lines common to the two branches. This is the same as the technique used in resolve and octopus merges, so we relocate that code to a shared function. Note that if there are no differences at the same location, this technique can lead to automatic resolution without conflict, combining everything from the 2 files. As with the other merges using this technique, we assume the user will inspect the result before saving. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Reviewed-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-merge-one-file: use a lowercase "usage:" stringDavid Aguilar2013-02-241-1/+1
|/ | | | | | | | Make the usage string consistent with Git. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'js/maint-merge-one-file-osx-expr'Junio C Hamano2011-10-131-1/+1
|\ | | | | | | | | * js/maint-merge-one-file-osx-expr: merge-one-file: fix "expr: non-numeric argument"
| * merge-one-file: fix "expr: non-numeric argument"Jay Soffian2011-10-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When invoking expr to compare two numbers, don't quote the variables which are the output of 'wc -c'. On OS X, this output includes spaces, which expr balks at: $ sz0=`wc -c </etc/passwd` $ sz1=`wc -c </etc/passwd` $ echo "'$sz0'" ' 3667' $ expr "$sz0" \< "$sz1" \* 2 expr: non-numeric argument $ expr $sz0 \< $sz1 \* 2 1 Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/merge-one-file-working-tree'Junio C Hamano2011-05-061-1/+6
|\ \ | | | | | | | | | | | | | | | * jk/merge-one-file-working-tree: merge-one-file: fix broken merges with alternate work trees add tests for merge-index / merge-one-file
| * | merge-one-file: fix broken merges with alternate work treesJeff King2011-04-291-1/+6
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The merge-one-file tool predates the invention of GIT_WORK_TREE. By the time GIT_WORK_TREE was invented, most people were using the merge-recursive strategy, which handles resolving internally. Therefore these features have had very little testing together. For the most part, merge-one-file just works with GIT_WORK_TREE; most of its heavy lifting is done by plumbing commands which do respect GIT_WORK_TREE properly. The one exception is a shell redirection which touches the worktree directly, writing results to the wrong place in the presence of a GIT_WORK_TREE variable. This means that merges won't even fail; they will silently produce incorrect results, throwing out the entire "theirs" side of files which need content-level merging! This patch makes merge-one-file chdir to the toplevel of the working tree (and exit if we don't have one). This most closely matches the assumption made by the original script (before separate work trees were invented), and matches what happens when the script is called as part of a merge strategy. While we're at it, we'll also error-check the call to cat. Merging a file in a subdirectory could in fact fail, as the redirection relies on the "checkout-index" call just prior to create leading directories. But we never noticed, since we ignored the error return from running cat. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | build: propagate $DIFF to scriptsJunio C Hamano2010-06-051-1/+1
| | | | | | | | | | | | | | git-merge-one-file expects to run "-u" capable "diff", but using $DIFF is not the right way to do so. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Do not use "diff" found on PATH while building and installingGary V. Vaughan2010-05-311-1/+1
|/ | | | | | | | Some of the flags used with the first diff found in PATH cause the vendor diff to choke. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Show usage string for 'git merge-one-file -h'Jonathan Nieder2009-11-101-0/+12
| | | | | Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Clarify kind of conflict in merge-one-file helperAlex Riesen2009-05-091-2/+9
| | | | | | | Not as verbose as the recursive merge driver, but better still. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-merge-one-file: fix longstanding stupid thinkoJunio C Hamano2008-03-181-2/+3
| | | | | | | | | When a merge result creates a new file, and when our side already has a file in the path, taking the merge result may clobber the untracked file. However, the logic to detect this situation was totally the wrong way. We should complain when the file exists, not when the file does not exist. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Support a merge with conflicting gitlink changeJunio C Hamano2007-12-111-0/+4
| | | | | | | | | | | | | | | | merge-recursive did not support merging trees that have conflicting changes in submodules they contain, and died. Support it exactly the same way as how it handles conflicting symbolic link changes --- mark it as a conflict, take the tentative result from the current side, and letting the caller resolve the conflict, without dying in merge_file() function. Also reword the error message issued when merge_file() has to die because it sees a tree entry of type it does not support yet. [jc: fixed up initial draft by Finn Arne Gangstad] Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix merge-one-file for our-side-added/our-side-removed casesJunio C Hamano2007-07-081-4/+6
| | | | | | | | | When commit ed93b449 changed the script so that it does not touch untracked working tree file, we forgot that we still needed to resolve the index entry (otherwise they are left unmerged). Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Rewrite "git-frotz" to "git frotz"Junio C Hamano2007-07-021-11/+11
| | | | | | This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* War on whitespaceJunio C Hamano2007-06-071-1/+1
| | | | | | | | | This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Use git-merge-file in git-merge-one-file, tooJohannes Schindelin2006-12-211-1/+1
| | | | | | | | Would you believe? I edited git-merge-one-file (note the missing ".sh"!) when I submitted the patch which became commit e2b7008752... Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge: loosen overcautious "working file will be lost" check.Junio C Hamano2006-10-271-1/+15
| | | | | | | | | | | | The three-way merge complained unconditionally when a path that does not exist in the index is involved in a merge when it existed in the working tree. If we are merging an old version that had that path tracked, but the path is not tracked anymore, and if we are merging that old version in, the result will be that the path is not tracked. In that case we should not complain. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix more typos, primarily in the codePavel Roskin2006-07-101-1/+1
| | | | | | | | | The only visible change is that git-blame doesn't understand "--compability" anymore, but it does accept "--compatibility" instead, which is already documented. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Shell utilities: Guard against expr' magic tokens.Mark Wooding2006-04-131-1/+1
| | | | | | | | | Some words, e.g., `match', are special to expr(1), and cause strange parsing effects. Track down all uses of expr and mangle the arguments so that this isn't a problem. Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
* trivial: remove the dots at the end of file names from merge-one-fileAlex Riesen2006-01-051-2/+2
| | | | | | | to make the output more friendly to mouse copy-paste. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge-one: new merge world order.Junio C Hamano2005-12-071-16/+9
| | | | | | | | | | | | | This does two things: - Use new --stage=2 option to create the working tree file with leading paths and correct permission bits using checkout-index, as before. - Make sure we do not confuse "merge" program when the file being merged has an unfortunate name, '-L'. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge-one-file: resurrect leading path creation.Junio C Hamano2005-12-061-2/+10
| | | | | | | | | | | | | | Since we do not use git-update-index followed by git-checkout-index -u to create the half-merged file on conflicting case anymore, we need to make sure the leading directories are created here. Maybe a better solution would be to allow update-index to add to higher stage, and checkout-index to extract from such, but that is a change slightly bigger than I would like to have so close to 1.0, so this should do for now. Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge-one-file: make sure we do not mismerge symbolic links.Junio C Hamano2005-12-021-0/+8
| | | | | | | We ran "merge" command on O->A, O->B, A!=B case without verifying the path involved is not a symlink. Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge-one-file: make sure we create the merged file.Junio C Hamano2005-12-021-1/+7
| | | | | | | | | | | The "update-index followed by checkout-index" chain served two purposes -- to collapse the index to "our" version, and make sure that file exists in the working tree. In the recent update to leave the index unmerged on conflicting path, we wanted to stop doing the former, but we still need to do the latter (we allow merging to work in an un-checked-out working tree). Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-merge-one-file: do not worry about 'rmdir -p' not removing directory.Junio C Hamano2005-12-011-1/+1
| | | | | | | | 9ae2172aed289f2706a0e88288909fa47eddd7e7 used "rmdir -p" carelessly, causing the more important "git-update-index --remove" to be skipped. Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge-one-file: leave unmerged index entries upon automerge failure.Linus Torvalds2005-11-301-5/+1
| | | | | | | | | | | When automerge fails, we used to collapse the path to stage0 from "our" branch, to help "diff-files" users to view the half-merged state against the current HEAD. Now diff-files has been taught how to compare with unmerged stage2,leaving them unmerged is a better thing to do, especially this prevents the unresolved conflicts to be committed by mistake. Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge-one-file: use rmdir -pJunio C Hamano2005-11-201-5/+1
| | | | | | The flag is universally available, even on VMS; use it. Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge-one-file: remove empty directoriesJunio C Hamano2005-11-191-1/+6
| | | | | | | | | | When the last file in a directory is removed as the result of a merge, try to rmdir the now-empty directory. [jc: We probably could use "rmdir -p", but for now we do that by hand for portability.] Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge-one-file: use empty- or common-base condintionally in two-stage merge.Junio C Hamano2005-11-111-0/+6
| | | | | | | | If two sides added the same path completely different thing, it is easier to see the merge pivoting on /dev/null. So check the size of the common section we have found, and empty it if it is too small. Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge-one-file: use common as base, instead of emptiness.Junio C Hamano2005-11-111-2/+4
| | | | | | | | | | | | | | | | | | | | | Unlike the previous round that merged the path added differently in each branches using emptiness as the base, compute a common version and use it as input to 'merge' program. This would show the resulting (still conflicting) file left in the working tree as: common file contents... <<<<<< FILENAME version from our branch... ====== version from their branch... >>>>>> .merge_file_XXXXXX more common file contents... when both sides added similar contents. Signed-off-by: Junio C Hamano <junkio@cox.net>
* merge with /dev/null as base, instead of punting O==empty caseJunio C Hamano2005-11-111-4/+16
| | | | | | | | | Instead of leaving the path unmerged in a case where each side adds different version of the same path, attempt to merge it with empty base and leave "our" version in the index file, just like we do for the case in conflicting merge. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Big tool rename.Junio C Hamano2005-09-071-0/+88
As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <junkio@cox.net>
View Lorry Controller Status