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

112 lines
2.4 KiB
Plaintext
Raw Normal View History

#!/bin/sh
#
# Copyright (c) Linus Torvalds, 2005
#
# This is the git per-file 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 might change the tree layout.
verify_path() {
file="$1"
dir=`dirname "$file"` &&
mkdir -p "$dir" &&
rm -f -- "$file" &&
: >"$file"
}
case "${1:-.}${2:-.}${3:-.}" in
#
# Deleted in both.
#
"$1..")
echo "WARNING: $4 is removed in both branches."
echo "WARNING: This is a potential rename conflict."
rm -f -- "$4" &&
exec git-update-cache --remove -- "$4"
;;
#
# Deleted in one and unchanged in the other.
#
"$1.$1" | "$1$1.")
echo "Removing $4"
rm -f -- "$4" &&
exec git-update-cache --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."
verify_path "$4" &&
git-cat-file blob "$2$3" >"$4" &&
chmod $mode -- "$4" &&
exec git-update-cache --add -- "$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"
verify_path "$4" &&
git-cat-file blob "$2" >"$4" &&
chmod $mode -- "$4" &&
exec git-update-cache --add -- "$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`
verify_path "$4" &&
merge -p "$src1" "$orig" "$src2" > "$4"
ret=$?
rm -f -- "$orig" "$src1" "$src2"
if [ "$6" != "$7" ]; then
echo "ERROR: Permissions conflict: $5->$6,$7."
ret=1
fi
case "$6" in *7??) mode=+x;; *) mode=-x;; esac
chmod "$mode" "$4"
if [ $ret -ne 0 ]; then
# Reset the index to the first branch, making
# git-diff-file useful
git-update-cache --add --cacheinfo "$6" "$2" "$4"
echo "ERROR: Merge conflict in $4."
exit 1
fi
exec git-update-cache --add -- "$4"
;;
*)
echo "ERROR: $4: Not handling case $1 -> $2 -> $3"
;;
esac
exit 1