git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [BUG] [RESOLVED] merge-recursive call in git-am -3 chokes, autocrlf issue?

From
Scott R. Godin <scottg.wp-hackers@mhg2.com>
Date
May 4, 2010, 21:47 UTC
Message-ID
<4BE095D9.6090403@mhg2.com>
In-Reply-To
<7vbpe3qe09.fsf@alter.siamese.dyndns.org>
On 04/01/2010 01:27 PM, Junio C Hamano wrote:
Show 12 quoted lines
> I however think the patch probably "fixes" the issue at the worst point.
> Wouldn't either of these alternatives be better?
>
>   (1) Perhaps the caller of "pre-commit/post-merge/post-checkout" hook
>       should instead refresh the index when the hook returns, _iff_ we
>       expect that majority of these hooks are used to munge the work tree
>       or the index; or
>
>   (2) Because you already established that setgitperms script is the
>       culprit that leaves the index unrefreshed, instead of forcing all the
>       callers of the script, it should do the refresh for its callers
>       before it exits.
Good call.

I talked it over with Todd Zullinger and he came up with the following patch, which I tested on my end to my complete satisfaction, rebases and merges go smoothly.

it's still necessary however, to --no-commit on merges so that you can fix the permissions before your umask blots them out and they wind up in the commit and saved in the gitmeta file

As a result, my usual modus operandi currently is:
	git checkout master
	git merge --no-ff --no-commit develop
	find . -perm 0600 -or -perm 0700 |grep -v .git/
	...fix perms back to where they should be
	git add -A
	git commit

which is somewhat less than optimal, but otherwise setgitperms.perl is doing what it should.

Revised patch follows:
--8<--
Subject: [PATCH] Revise setgitperms.perl to fix dirty tree problem when 
rebasing/merging

reference: http://comments.gmane.org/gmane.comp.version-control.git/142548

Note that it will be necessary to not only copy the changed
setgitperms.perl from /usr/share/git-core/contrib/hooks/ to
/usr/share/git-core/templates/hooks/ but additionally every git
repository you currently use this script with, will also need to be
updated with the new version. This process is regrettably not automatic 
simply
because git was updated on your system.
---
  contrib/hooks/setgitperms.perl |    4 ++++
  1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/contrib/hooks/setgitperms.perl b/contrib/hooks/setgitperms.perl
index a577ad0..e571560 100644
--- a/contrib/hooks/setgitperms.perl
+++ b/contrib/hooks/setgitperms.perl
@@ -91,6 +91,10 @@ if ($write_mode) {
         }
      }
      close IN;
+
+    # Make sure the index isn't left dirty
+    # http://comments.gmane.org/gmane.comp.version-control.git/142548
+    system("git update-index --refresh");
  }
  elsif ($read_mode) {
      # Handle merge conflicts in the .gitperms file
-- 
1.7.1

--8<--

-- 
(please respond to the list as opposed to my email box directly,
unless you are supplying private information you don't want public
on the list)
Previous: Junio C HamanoNext: Scott R. Godin
Message 4 of 6 in “[BUG] merge-recursive call in git-am -3 chokes, autocrlf issue?”
  1. Thomas RastMar 19, 2010
  2. Scott R. GodinApr 1, 2010
  3. Junio C HamanoApr 1, 2010
  4. Scott R. GodinMay 4, 2010
  5. setgitperms.perl dirty index problem (was Re: [BUG] [RESOLVED] merge-recursive call in git-am -3 chokes, autocrlf issue?)Scott R. Godin, May 24, 2010
  6. Junio C HamanoMay 25, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.