[PATCH] Really fix git-merge-one-file-script this time.
authorJunio C Hamano <junkio@cox.net>
Sun, 1 May 2005 16:33:12 +0000 (09:33 -0700)
committerLinus Torvalds <torvalds@ppc970.osdl.org>
Sun, 1 May 2005 16:33:12 +0000 (09:33 -0700)
commit21a08dcbe70a79206b76c89fb95e26d3a7fdf1f4
treebb09128b904d6ac085134fd772ae79db7ecca3a6
parent5d2f8b2753183e6cf2238a6f2d847e54211ba11f
[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>
git-merge-one-file-script