git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Scott R. Godin" <scottg.wp-hackers@mhg2.com>
To: git@vger.kernel.org
Subject: [PATCH] setgitperms.perl dirty index problem (was Re: [BUG] [RESOLVED] merge-recursive call in git-am -3 chokes, autocrlf issue?)
Date: Mon, 24 May 2010 13:09:28 -0400	[thread overview]
Message-ID: <htebs9$ann$1@dough.gmane.org> (raw)
In-Reply-To: <4BE095D9.6090403@mhg2.com>

On 05/04/2010 05:47 PM, Scott R. Godin wrote:

Hadn't seen any response to this so I'm reposting in the hopes that this 
will make it to the next release.

> On 04/01/2010 01:27 PM, Junio C Hamano wrote:
>> 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


-- 
(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)

  reply	other threads:[~2010-05-24 17:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-19  0:49 [BUG] merge-recursive call in git-am -3 chokes, autocrlf issue? Thomas Rast
2010-04-01 17:03 ` [BUG] [RESOLVED] " Scott R. Godin
2010-04-01 17:27   ` Junio C Hamano
2010-05-04 21:47     ` Scott R. Godin
2010-05-24 17:09       ` Scott R. Godin [this message]
2010-05-25  5:37         ` [PATCH] setgitperms.perl dirty index problem Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='htebs9$ann$1@dough.gmane.org' \
    --to=scottg.wp-hackers@mhg2.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).