summaryrefslogtreecommitdiff
path: root/git-merge-one-file-script
AgeCommit message (Collapse)AuthorFilesLines
2005-07-29[PATCH] Trivial tidyupsLibravatar Petr Baudis1-4/+3
Simple whitespace-related tidyups ensuring style consistency. This is carried over from my old git-pb branch. Signed-off-by: Petr Baudis <pasky@ucw.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-06-25[PATCH] git-merge-one-file-script: do not misinterpret rm failure.Libravatar Junio C Hamano1-2/+5
When a merge adds a file DF and removes a directory there by deleting a path DF/DF, git-merge-one-file-script can be called for the removal of DF/DF when the path DF is already created by "git-read-tree -m -u". When this happens, we get confused by a failure return from 'rm -f -- "$4"' (where $4 is DF/DF); finding file DF there the "rm -f" command complains that DF is not a directory. What we want to ensure is that there is no file DF/DF in this case. Avoid getting ourselves confused by first checking if there is a file, and only then try to remove it (and check for failure from the "rm" command). Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-08One more time.. Clean up git-merge-one-file-scriptLibravatar Linus Torvalds1-42/+15
This uses git-checkout-file to make sure that the full pathname is created, instead of the script having to verify it by hand. Also, simplify the 3-way merge case by just writing to the right file and setting the initial index contents early.
2005-06-08Fix up git-merge-one-file-scriptLibravatar Linus Torvalds1-7/+18
Junio points out that we may need to create the path leading up the the file we merge. And we need to be more careful with the "exec"s we've done to exit on success - only do the on the last command in the pipeline, not the first one ;)
2005-06-08Merge my and Petr's git-merge-one-file-script modificationsLibravatar Linus Torvalds1-1/+2
2005-06-08[PATCH] git-merge-one-file-script cleanups from CogitoLibravatar Petr Baudis1-15/+29
Chain the resolving sequences (e.g. git-cat-file - chmod - git-update-cache) through &&s so we stop right away in case one of the command fails, and report the error code to the script caller. Also add a copyright notice, some blank lines, ;; on a separate line, and nicer error messages. Signed-off-by: Petr Baudis <pasky@ucw.cz> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-08Make sure we error out if we can't remove a file on automatic merges.Libravatar Linus Torvalds1-1/+2
Pointed out by Junio.
2005-06-08[PATCH] Fix git-merge-one-file permissions auto-mergingLibravatar Petr Baudis1-0/+4
In the automerge case, permissions were not restored properly after the merge tool was invoked and overwrote the target file. Signed-off-by: Petr Baudis <pasky@ucw.cz> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-08Leave merge failures in the filesystemLibravatar Linus Torvalds1-12/+19
This changes how we handle merges: if a automated merge fails, we will leave the index as a clean entry pointing to the original branch, and leave the actual file _dirty_ the way the "merge" program left it. You can then just do "git-diff-files -p" to see what the merge conflicts did, fix them up, and commit the end result. NOTE NOTE NOTE! Do _not_ use "git commit" to commit such a merge. It won't set the parents right. I'll need to fix that. In the meantime, you'd need to merge using git-commit-tree $(git-write) -p HEAD -p MERGE_HEAD or something like that by hand.
2005-05-07Use backticks in git-merge-one-file-script instead of $(command).Libravatar Junio C Hamano1-4/+4
Thomas Glanzmann says that shell he uses on Solaris cannot grok $(command) but the script does not use nested $(command) and works happily just by using backticks instead. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-05-01Update git-merge-one-file-script.Libravatar Junio C Hamano1-38/+26
With this change, git-merge-one-file-script ceases to smudge files in the work tree when recording the trivial merge results (conflicting auto-merge failure case does not touch the work tree file as before). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-05-01[PATCH] Really fix git-merge-one-file-script this time.Libravatar Junio C Hamano1-23/+18
The merge-cache program was updated to pass executable bits when calling git-merge-one-file-script, but the called script supplied as an example were not using them carefully. This patch fixes the following problems in the script: * When a new file is created in a directory, which is a file in the work tree, it tried to create leading directory but did not check for failure from the "mkdir -p" command. * The script did not check the exit status from the git-update-cache command at all. * The parameter "$4" to the script is a file name that can contain almost any characters, so it must be quoted with double quotes and also needs to be preceded with -- to mark it as a non-option when passed to certain commands. * The chmod command was used with parameter "$6" or "$7" to set the mode bits. This contradicts with the strategy taken by checkout-cache, where we honor user's umask and force only the executable bits. With this patch, it creates a new file by redirecting into it (thus honoring user's default umask), and then uses "chmod +x" if we want the resulting file executable. Without this fix, the merge result becomes 0644 or 0755 for users whose umask is 002 for whom it should become 0664 or 0775. * When "$1 -> $2 -> $3" case was not handled, the script did not say which path it was working on, which was not so useful when used with the -a option of git-merge-cache. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-29[PATCH] leftover bits for git renameLibravatar Junio C Hamano1-3/+3
Linus said: "Let's see what else I forgot.." Not that many, but here they are. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-29Update the merge scripts for the big git rename.Libravatar Linus Torvalds1-7/+7
Let's see what else I forgot..
2005-04-23[PATCH] make file merging respect permissionsLibravatar James Bottomley1-8/+39
1) permissions aren't respected in the merge script (primarily because they're never passed in to it in the first place). Fix that and also check for permission conflicts in the merge 2) the delete of a file in both branches may indeed be just that, but it could also be the indicator of a rename conflict (file moved to different locations in both branches), so error out and ask the committer for guidance. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-18[PATCH] SCSI trees, merges and git statusLibravatar James Bottomley1-1/+10
Doing the latest SCSI merge exposed two bugs in your merge script: 1) It doesn't like a completely new directory (the misc tree contains a new drivers/scsi/lpfc) 2) the merge testing logic is wrong. You only want to exit 1 if the merge fails.
2005-04-18Change merge-cache and git-merge-one-file to use the SHA1 of the fileLibravatar Linus Torvalds1-22/+38
instead of a checked-out temporary copy. If merging requires a checked-out-copy, we now do so with "unpack-file".
2005-04-18Add the simple scripts I used to do a merge with content conflicts.Libravatar Linus Torvalds1-0/+35
They sure as hell aren't perfect, but they allow you to do: ./git-pull-script {other-git-directory} to do the initial merge, and if that had content clashes, you do merge-cache ./git-merge-one-file-script -a which tries to auto-merge. When/if the auto-merge fails, it will leave the last file in your working directory, and you can edit it and then when you're happy you can do "update-cache filename" on it. Re-do the merge-cache thing until there are no files left to be merged, and now you can write the tree and commit: write-tree commit-tree .... -p $(cat .git/HEAD) -p $(cat .git/MERGE_HEAD) and you're done.