threads / discuss / 12883

git add -i doesn't update permissions

Subject: git add -i doesn't update permissions

## tl;dr

5 messages between Mar 26, 2008 and Mar 27, 2008.

replies: 4people: 4as markdown or json

Jörg Sommer· Mar 26, 2008, 10:23 UTC · lore
Hi,
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index 77c90f6..424271c 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -66,4 +66,14 @@ test_expect_success 'revert works (commit)' '
        grep "unchanged *+3/-0 file" output
 '
 
+test_expect_success 'update file permissions' '
+       git reset --hard &&
+       chmod +x file &&
+       printf "p\n1\n" | git add -i
+'
+
+test_expect_failure "update file permissions doesn't work" '
+       git status
+'
+
 test_done

Bye, Jörg.

-- 
Unsere Zweifel sind Verräter und oft genug verspielen wir den möglichen
Gewinn, weil wir den Versuch nicht wagen.
Jeff King· Mar 27, 2008, 05:57 UTC · re: Jörg Sommer · lore

Re: git add -i doesn't update permissions

On Wed, Mar 26, 2008 at 11:23:32AM +0100, Jörg Sommer wrote:
Show 5 quoted lines
> +test_expect_success 'update file permissions' '
> +       git reset --hard &&
> +       chmod +x file &&
> +       printf "p\n1\n" | git add -i
> +'

I'm not sure this is really a bug (but rather a feature request, which I will explain below). add--interactive has two modes for moving changes to files into the index:

  1. 'u' will 'update' the file in the index, adding the new content and
     any mode changes
  2. 'p' will show you each patch hunk from the file, which can then
     either be added or not.

You are using 'p' and expecting it to work with the file mode, when it is purely about picking content hunks.

So I think the test _should_ be
  printf "u\n1\n" | git add -i
in which case it works fine.

Now, if you are interested in adding the mode change of a file but _not_ its content, I think that is a reasonable thing to ask for. And it's something that is not possible with "add -i" right now, I don't think. You seemed to expect that 'p' would present the mode change and say "do you want to stage this?" which I think is a reasonable interface. Though in that case "[p]atch" should perhaps be "[p]artial update".

-Peff
Jeff King· Mar 27, 2008, 06:29 UTC · re: Jeff King · lore

Re: git add -i doesn't update permissions

On Thu, Mar 27, 2008 at 01:57:46AM -0400, Jeff King wrote:
Show 5 quoted lines
>   2. 'p' will show you each patch hunk from the file, which can then
>      either be added or not.
> 
> You are using 'p' and expecting it to work with the file mode, when it
> is purely about picking content hunks.

Actually, it is a little more complex than that. "git add -p" will reuse the header from "git diff", so it will not apply a mode change _unless_ any hunk is selected.

So probably the right behavior is to split the header into "boilerplate" and "mode change", and then ask whether the mode change should be included.

-Peff
Wincent Colaiuta· Mar 27, 2008, 06:32 UTC · re: Jeff King · lore

Re: git add -i doesn't update permissions

El 27/3/2008, a las 6:57, Jeff King escribió:
Show 9 quoted lines
> Now, if you are interested in adding the mode change of a file but  
> _not_
> its content, I think that is a reasonable thing to ask for. And it's
> something that is not possible with "add -i" right now, I don't think.
> You seemed to expect that 'p' would present the mode change and say  
> "do
> you want to stage this?" which I think is a reasonable interface.  
> Though
> in that case "[p]atch" should perhaps be "[p]artial update".
Or even "[p]ick" (changes to be staged), which is a bit shorter.

But yes, I've always thought that "[p]atch" didn't really describe what that subcommand really does.

Cheers, Wincent

Junio C Hamano· Mar 27, 2008, 16:08 UTC · re: Jeff King · lore

Re: git add -i doesn't update permissions

Jeff King <peff@peff.net> writes:
> Now, if you are interested in adding the mode change of a file but _not_
> its content, I think that is a reasonable thing to ask for. And it's
> something that is not possible with "add -i" right now, I don't think.

It's worse than that. It _theoretically_ is possible that this limitation becomes problematic if you are in this situation:

 1. Notice a problem in the gostak script that it should distim doshes but
    it doesn't.
 2. Start working to change the gostak script.
 3. Notice that the gistak script itself needs the +x bit but it doesn't.
 4. Being a very disciplined person, you want to make sequence of commits
    that record each separate logical change as a separate commit.  You
    would want to record "Add executable bit to the gostak script" first,
    and then work further on the contents of the script to make "Enhance
    the gostak script to distim doshes" as two logically separate steps.
	
This is not something you can do with "git add" in general, although I do
not see how this can be an issue in real life.
Two already available solutions are:
 (1) git reset HEAD -- gostak ;# undo staged content changes
     git update-index --chmod=+x gostak
     git commit -m "Add executable bit to the gostak script"
     edit gostak ;# work more
     git add gostak
     git commit -m "Enhance the gostak script to distim doshes"
 (2) git stash ;# undo changes
     chmod +x gostak
     git add gostak
     git commit -m "Add executable bit to the gostak script"
     git stash pop ;# take the wip changes back
     edit gostak ;# work more
     git add gostak
     git commit -m "Enhance the gostak script to distim doshes"

← back to recent threads