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
Apr 1, 2010, 17:03 UTC
Message-ID
<hp2jkj$mu0$1@dough.gmane.org>
In-Reply-To
<201003190149.03025.trast@student.ethz.ch>
On 03/18/2010 08:49 PM, Thomas Rast wrote:
> Hi everyone,
>
> I helped Scott R. "WebDragon" Godin on IRC[1] with a bug internal to
> git-rebase.  It manifests like this:
It turns out it's not actually a bug in git-am/git-rebase.

while changing merge-recursive to merge-resolve in git-am solved the plain git rebase branch1 branch2 issue, I still ran into trouble when trying to do a rebase -i so I could squash a commit or two together.

Ilari stepped up to the plate [1] and it was quickly determined that the working copy cache is somehow left dirty after checkout.

doener stepped back in, and while pulling the hooks out that used setgitperms.perl, temporarily, it became obvious that one of them was the culprit, and further testing at this point would allow the rebase to continue, albiet without permissions being set. using git update-index --refresh allowed things to go on normally, when added to the post-checkout hook calling setgitperms.perl [2].

So my recommendation at this point is to patch the instructions within setgitperms.perl to add 'git update-index --refresh' to the end of the post-checkout hook.

I've since reset git-am to use recursive again (instead of resolve) and done several rebases (both with and without -i) and all seems well and normal, and this has made my day.

patch follows:
--8<--
Subject: [PATCH] revise setgitperms.perl hook script description to fix 
rebase issue
add index-refresh command to post-checkout post-merge script hooks to 
keep working tree from being marked dirty during a rebase action
---
  contrib/hooks/setgitperms.perl |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/hooks/setgitperms.perl b/contrib/hooks/setgitperms.perl
index a577ad0..286835d 100644
--- a/contrib/hooks/setgitperms.perl
+++ b/contrib/hooks/setgitperms.perl
@@ -17,6 +17,7 @@
  #      #!/bin/sh
  #     SUBDIRECTORY_OK=1 . git-sh-setup
  #     $GIT_DIR/hooks/setgitperms.perl -w
+#     git update-index --refresh
  #
  use strict;
  use Getopt::Long;

--8<--

[1] http://colabti.org/irclogger/irclogger_log/git?date=2010-03-31#l1556
[2] http://colabti.org/irclogger/irclogger_log/git?date=2010-03-31#l1743
-- 
(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: Thomas RastNext: Junio C Hamano
Message 2 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.