summaryrefslogtreecommitdiff
path: root/git-merge-one-file.sh
AgeCommit message (Collapse)AuthorFilesLines
2008-03-18git-merge-one-file: fix longstanding stupid thinkoLibravatar Junio C Hamano1-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>
2007-12-11Support a merge with conflicting gitlink changeLibravatar Junio C Hamano1-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>
2007-07-08Fix merge-one-file for our-side-added/our-side-removed casesLibravatar Junio C Hamano1-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>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-11/+11
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-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>
2006-12-21Use git-merge-file in git-merge-one-file, tooLibravatar Johannes Schindelin1-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>
2006-10-27merge: loosen overcautious "working file will be lost" check.Libravatar Junio C Hamano1-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>
2006-07-10Fix more typos, primarily in the codeLibravatar Pavel Roskin1-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>
2006-04-13Shell utilities: Guard against expr' magic tokens.Libravatar Mark Wooding1-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>
2006-01-05trivial: remove the dots at the end of file names from merge-one-fileLibravatar Alex Riesen1-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>
2005-12-07git-merge-one: new merge world order.Libravatar Junio C Hamano1-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>
2005-12-06git-merge-one-file: resurrect leading path creation.Libravatar Junio C Hamano1-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>
2005-12-02merge-one-file: make sure we do not mismerge symbolic links.Libravatar Junio C Hamano1-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>
2005-12-02merge-one-file: make sure we create the merged file.Libravatar Junio C Hamano1-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>
2005-12-01git-merge-one-file: do not worry about 'rmdir -p' not removing directory.Libravatar Junio C Hamano1-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>
2005-11-30merge-one-file: leave unmerged index entries upon automerge failure.Libravatar Linus Torvalds1-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>
2005-11-20merge-one-file: use rmdir -pLibravatar Junio C Hamano1-5/+1
The flag is universally available, even on VMS; use it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19merge-one-file: remove empty directoriesLibravatar Junio C Hamano1-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>
2005-11-11merge-one-file: use empty- or common-base condintionally in two-stage merge.Libravatar Junio C Hamano1-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>
2005-11-11merge-one-file: use common as base, instead of emptiness.Libravatar Junio C Hamano1-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>
2005-11-11merge with /dev/null as base, instead of punting O==empty caseLibravatar Junio C Hamano1-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>
2005-09-07Big tool rename.Libravatar Junio C Hamano1-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>