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>
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.
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 ;)
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>
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>
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.
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>
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>
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>
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>
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>
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.
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.
