summaryrefslogtreecommitdiff
path: root/git-merge-one-file-script
AgeCommit message (Collapse)Author
2005-09-08Big tool rename.Junio C Hamano
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>
2005-08-30[PATCH] Make "git resolve" less scaryLinus Torvalds
When we resolve a merge between two branches, and it removes a file in the current branch, we notify the person doing the resolve with a big nice notice like Removing xyzzy which is all well and good. HOWEVER, we also do this when the file was actually removed in the current branch, and we're merging with another branch that didn't have it removed (or, indeed, if the other branch _did_ have it removed, but the common parent was far enough back that the file still existed in there). And that just doesn't make sense. In that case we're not removing anything: the file didn't exist in the branch we're merging into in the first place. So the message just makes people nervous, and makes no sense. This has been around forever, but I never bothered to do anything about it. Until now. The trivial fix is to only talk about removing files if the file existed in the branch we're merging into, but will not exist in the result. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-30[PATCH] Trivial tidyupsPetr Baudis
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.Junio C Hamano
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-09One more time.. Clean up git-merge-one-file-scriptLinus Torvalds
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-09Fix up git-merge-one-file-scriptLinus Torvalds
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 modificationsLinus Torvalds
2005-06-08[PATCH] git-merge-one-file-script cleanups from CogitoPetr Baudis
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.Linus Torvalds
Pointed out by Junio.
2005-06-08[PATCH] Fix git-merge-one-file permissions auto-mergingPetr Baudis
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 filesystemLinus Torvalds
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).Junio C Hamano
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-02Update git-merge-one-file-script.Junio C Hamano
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.Junio C Hamano
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 renameJunio C Hamano
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.Linus Torvalds
Let's see what else I forgot..
2005-04-24[PATCH] make file merging respect permissionsJames Bottomley
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-19[PATCH] SCSI trees, merges and git statusJames Bottomley
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 fileLinus Torvalds
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.Linus Torvalds
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.