rebase, file permissions and removed file

In short,

   - a branch is created
   - a file is removed from master
   - the same file has its permissions changed on the branch
   - we rebase the branch on master
   - how to resolve the conflict?

Following is a script to reproduce the problem, see comment at the end.

Any idea? Thanks.

<< -- #!/bin/sh

rm -fr repo

mkdir repo cd repo git init

touch file1 file2 chmod a+x file* git add . git ci -m "First rev"

git checkout -b fixperms chmod a-x file1 git add file1 git ci -m "Fix perm file1"

git checkout master git rm file1 git ci -m "Remove file1"

git checkout fixperms

git rebase master

# At this point there is a conflict as expected # file1 has been removed on master, and file1 had its permissions changed # on fixperms branch. # # What I find confusing is that: # $ git diff # and # $ git diff --cached # # are reporting nothing. # # Ok, file1 has been removed, let's then remove it as it is right: # # $ git rm file1 # fatal: pathspec 'file1' did not match any files # # Ok, so what's the proper way to fix that! What should I do to be able to # continue the rebase: # # $ git rebase --continue

--

--|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Pascal Obry schrieb:

Since you don't have any content to lose, you can always just

 $ touch file1
 $ git add file1
 $ git rm file1

-- Hannes

On Mon, Oct 27, 2008 at 3:38 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:

Does not work:

$ git rebase --continue
Applying: Fix perm file1
No changes - did you forget to use 'git add'?

When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort".

The only solution I found is to abort the rebase, edit my topic branch (fixperms in this example) to remove file1 from the commit and redo the rebase... Not that simple especially since there was many other commits on my topic branch.

Pascal Obry schrieb:

Yes, it did! ;)

This is an entirely different matter. My interpretation is that the permission change of file1 was the only change in this commit. Since this is no longer needed, you should run 'git rebase --skip'.

-- Hannes

On Mon, Oct 27, 2008 at 4:21 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:

Well, on my side I add to use:

   $ git rm --cached file1

For the last command.

No no :) Too easy! I have plenty of other permission changes in my commit that I do not want to loose!

Pascal.

Pascal> I have plenty of other permission changes in my commit that I Pascal> do not want to loose!

Why do you do a "rebase" in this case rather than a merge? Doesn't it make little sense to record a permission change on a *deleted* file?

  Sam

Samuel Tardieu a écrit :

Because this is in the context of git-svn, and I really want to rebase my work before pushing it back to the Subversion repository.