git-commit-vandalism/git-merge-one-file-script

75 lines
1.9 KiB
Plaintext
Raw Normal View History

#!/bin/sh
#
# This is the git merge script, called with
#
# $1 - original file SHA1 (or empty)
# $2 - file in branch1 SHA1 (or empty)
# $3 - file in branch2 SHA1 (or empty)
# $4 - pathname in repository
# $5 - orignal file mode (or empty)
# $6 - file in branch1 mode (or empty)
# $7 - file in branch2 mode (or empty)
#
# Handle some trivial cases.. The _really_ trivial cases have
# been handled already by git-read-tree, but that one doesn't
# do any merges that migth change the tree layout.
case "${1:-.}${2:-.}${3:-.}" in
#
# Deleted in both.
#
"$1..")
echo "ERROR: $4 is removed in both branches."
echo "ERROR: This is a potential rename conflict."
exit 1;;
#
# Deleted in one and unchanged in the other.
#
"$1.." | "$1.$1" | "$1$1.")
echo "Removing $4"
exec git-update-cache --force-remove "$4" ;;
#
# Added in one.
#
".$2." | "..$3" )
[PATCH] Really fix git-merge-one-file-script this time. 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-05-01 18:33:12 +02:00
case "$6$7" in *7??) mode=+x;; *) mode=-x;; esac
echo "Adding $4 with perm $mode."
exec git-update-cache --add --cacheinfo "$6$7" "$2$3" "$4" ;;
#
# Added in both (check for same permissions).
#
".$3$2")
if [ "$6" != "$7" ]; then
echo "ERROR: File $4 added identically in both branches,"
echo "ERROR: but permissions conflict $6->$7."
exit 1
fi
[PATCH] Really fix git-merge-one-file-script this time. 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-05-01 18:33:12 +02:00
case "$6" in *7??) mode=+x;; *) mode=-x;; esac
echo "Adding $4 with perm $mode"
exec git-update-cache --add --cacheinfo "$6" "$2" "$4" ;;
#
# Modified in both, but differently.
#
"$1$2$3")
echo "Auto-merging $4."
orig=`git-unpack-file $1`
src1=`git-unpack-file $2`
src2=`git-unpack-file $3`
merge "$src2" "$orig" "$src1"
ret=$?
if [ "$6" != "$7" ]; then
echo "ERROR: Permissions $5->$6->$7 don't match."
fi
if [ $ret -ne 0 ]; then
echo "ERROR: Leaving conflict merge in $src2."
exit 1
fi
sha1=`git-write-blob "$src2"` || {
echo "ERROR: Leaving conflict merge in $src2."
}
exec git-update-cache --add --cacheinfo "$6" $sha1 "$4" ;;
*)
echo "ERROR: Not handling case $4: $1 -> $2 -> $3" ;;
esac
exit 1