2005-04-18 21:15:10 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
#
|
|
|
|
|
# This is the git merge script, called with
|
|
|
|
|
#
|
2005-04-18 23:17:58 +02:00
|
|
|
# $1 - original file SHA1 (or empty)
|
|
|
|
|
# $2 - file in branch1 SHA1 (or empty)
|
|
|
|
|
# $3 - file in branch2 SHA1 (or empty)
|
2005-04-18 21:15:10 +02:00
|
|
|
# $4 - pathname in repository
|
|
|
|
|
#
|
|
|
|
|
#
|
2005-04-18 23:17:58 +02:00
|
|
|
# Handle some trivial cases.. The _really_ trivial cases have
|
2005-04-30 01:25:05 +02:00
|
|
|
# been handled already by git-read-tree, but that one doesn't
|
2005-04-18 23:17:58 +02:00
|
|
|
# do any merges that migth change the tree layout
|
2005-04-18 21:15:10 +02:00
|
|
|
#
|
2005-04-18 23:17:58 +02:00
|
|
|
|
2005-04-19 04:55:19 +02:00
|
|
|
# if the directory is newly added in a branch, it might not exist
|
|
|
|
|
# in the current tree
|
|
|
|
|
dir=$(dirname "$4")
|
[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
|
|
|
mkdir -p "$dir" || exit
|
2005-04-19 04:55:19 +02:00
|
|
|
|
2005-04-18 23:17:58 +02:00
|
|
|
case "${1:-.}${2:-.}${3:-.}" in
|
2005-04-18 21:15:10 +02:00
|
|
|
#
|
2005-04-24 05:50:10 +02:00
|
|
|
# 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
|
2005-04-18 21:15:10 +02:00
|
|
|
#
|
2005-04-18 23:17:58 +02:00
|
|
|
"$1.." | "$1.$1" | "$1$1.")
|
2005-04-24 05:50:10 +02:00
|
|
|
echo "Removing $4"
|
[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
|
|
|
rm -f -- "$4" && exec git-update-cache --remove -- "$4" ;;
|
2005-04-18 21:15:10 +02:00
|
|
|
#
|
2005-04-24 05:50:10 +02:00
|
|
|
# added in one
|
2005-04-18 21:15:10 +02:00
|
|
|
#
|
2005-04-24 05:50:10 +02:00
|
|
|
".$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"
|
|
|
|
|
rm -f -- "$4" &&
|
|
|
|
|
git-cat-file blob "$2$3" >"$4" &&
|
|
|
|
|
chmod "$mode" -- "$4" &&
|
|
|
|
|
exec git-update-cache --add -- "$4" ;;
|
2005-04-24 05:50:10 +02:00
|
|
|
#
|
|
|
|
|
# Added in both (check for same permissions)
|
|
|
|
|
#
|
|
|
|
|
".$2$2")
|
|
|
|
|
if [ "$6" != "$7" ]; then
|
|
|
|
|
echo "ERROR: File $4 added in both branches, 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"
|
|
|
|
|
rm -f -- "$4" &&
|
|
|
|
|
git-cat-file blob "$2" >"$4" &&
|
|
|
|
|
chmod "$mode" -- "$4" &&
|
|
|
|
|
exec git-update-cache --add -- "$4" ;;
|
2005-04-18 23:17:58 +02:00
|
|
|
#
|
|
|
|
|
# Modified in both, but differently ;(
|
|
|
|
|
#
|
|
|
|
|
"$1$2$3")
|
|
|
|
|
echo "Auto-merging $4"
|
2005-04-30 00:02:43 +02:00
|
|
|
orig=$(git-unpack-file $1)
|
|
|
|
|
src1=$(git-unpack-file $2)
|
|
|
|
|
src2=$(git-unpack-file $3)
|
2005-04-19 04:55:19 +02:00
|
|
|
merge "$src2" "$orig" "$src1"
|
2005-04-24 05:50:10 +02:00
|
|
|
ret=$?
|
|
|
|
|
if [ "$6" != "$7" ]; then
|
|
|
|
|
echo "ERROR: Permissions $5->$6->$7 don't match merging $src2"
|
|
|
|
|
if [ $ret -ne 0 ]; then
|
|
|
|
|
echo "ERROR: Leaving conflict merge in $src2"
|
|
|
|
|
fi
|
|
|
|
|
exit 1
|
|
|
|
|
fi
|
|
|
|
|
if [ $ret -ne 0 ]; then
|
|
|
|
|
echo "ERROR: Leaving conflict merge in $src2"
|
2005-04-19 04:55:19 +02:00
|
|
|
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
|
|
|
|
|
rm -f -- "$4" && cat "$src2" >"$4" && chmod "$mode" -- "$4" &&
|
|
|
|
|
exec git-update-cache --add -- "$4" ;;
|
2005-04-18 23:17:58 +02:00
|
|
|
*)
|
[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
|
|
|
echo "Not handling case $4: $1 -> $2 -> $3" ;;
|
2005-04-18 23:17:58 +02:00
|
|
|
esac
|
|
|
|
|
exit 1
|
