git-flow @0.4.1_1 git flow feature finish with conflict -> error

[philippe.lang@…]

There seems to be a problem when finishing a feature with conflicts:

[MBP git_test (feature/b)]$ git flow feature finish b
Switched to branch 'develop'
Auto-merging file1.txt
CONFLICT (content): Merge conflict in file1.txt
Automatic merge failed; fix conflicts and then commit the result.
mkdir: /.gitflow: Permission denied
/opt/local/bin/git-flow-feature: line 320: /.gitflow/MERGE_BASE: No such file or directory

There were merge conflicts. To resolve the merge conflict manually, use:
    git mergetool
    git commit

You can then complete the finish by running it again:
    git flow feature finish b

Apparently a permission problem.

I don't know if that problem is related to git-flow itself, or the OSX port, so I mentioned that problem on github as well: ​https://github.com/nvie/gitflow/issues/370

[gorticus (Jason Mitchell)]

At first glance, it appears that $DOT_GIT_DIR is not properly set. It may be a while before I get time to debug anything useful. Could you provide a little more information on how you reproduce the issue?

As an aside, the nvie branch has not been maintained for some time. I have an update to the git-flow Portfile that contains subports for the more up-to-date AVH Edition and hubflow for use w/ GitHub. I'm still working out the kinks in the completion subports, so it's not ready for submission just yet. Perhaps I should submit the update without the completions, and add those later?

[gorticus (Jason Mitchell)]

Works for me:

$ mkdir x
$ cd x/
$ git init .
Initialized empty Git repository in /.../x/.git/
$ git flow init
...
$ git flow feature start f1
Switched to a new branch 'feature/f1'
...
$ touch file1.txt
$ git add file1.txt
$ git commit file1.txt -m"f1: add file"
...
$ git flow feature finish f1
Switched to branch 'develop'
Updating 1fe2597..3e8d799
Fast-forward
 file1.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file1.txt
Deleted branch feature/f1 (was 3e8d799).

Summary of actions:
- The feature branch 'feature/f1' was merged into 'develop'
- Feature branch 'feature/f1' has been locally deleted
- You are now on branch 'develop'
$ git log --decorate --oneline
3e8d799 (HEAD, develop) f1: add file
1fe2597 (master) Initial commit

Granted, this was a fast-forward exercise, but things seem to be set properly for me, using macports 2.3.1, git-flow @0.4.1_1.

Did I miss something in the case setup?

[philippe.lang@…]

Hi,

Here is a sequence that reproduces the permission error:

mkdir foo
cd foo
git init .
git flow init
git flow feature start f1
git checkout develop
git flow feature start f2
git checkout feature/f1
echo "content1" > file.txt
git add file.txt
git commit -m "commit"
git flow feature finish f1
git checkout feature/f2
echo "content2" > file.txt
git add file.txt
git commit -m "commit"
git flow feature finish f2

The last command gives:

Switched to branch 'develop'
Auto-merging file.txt
CONFLICT (add/add): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.
mkdir: /.gitflow: Permission denied
/opt/local/bin/git-flow-feature: line 320: /.gitflow/MERGE_BASE: No such file or directory

There were merge conflicts. To resolve the merge conflict manually, use:
    git mergetool
    git commit

You can then complete the finish by running it again:
    git flow feature finish f2

I could also see the problem is certainly related to "$DOT_GIT_DIR". But how/why, I don't know!

As a side-note, I would like to add that the OSX Git App "Tower 2.0" is bundled with git 2.0.0, and I'm not able to reproduce the bug with it, from the UI.

[gorticus (Jason Mitchell)]

When I try the recipe above, I also see the merge conflict, which I believe is the correct response for the actions. However, I do not receive the Permission denied error from git-flow-feature:

$ git flow finish f2
Switched to branch 'develop'
Auto-merging file.txt
CONFLICT (add/add): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.

There were merge conflicts. To resolve the merge conflict manually, use:
    git mergetool
    git commit

You can then complete the finish by running it again:
    git flow feature finish f2

[philippe.lang@…]

Hi, the conflict is perfectly normal, yes. Only the Permission Denied is a problem. An idea how to track the problem maybe? Do you know where git-flow is trying to create the directory? We could compare the permission we have there each other.

[gorticus (Jason Mitchell)]

Replying to philippe.lang@…:

Hi, the conflict is perfectly normal, yes. Only the Permission Denied is a problem. An idea how to track the problem maybe? Do you know where git-flow is trying to create the directory? We could compare the permission we have there each other.

Since on my 10.9.4, both /bin/bash and /bin/sh report GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13), I invoked the git-flow script manually with some options to produce debug-like output:

$ /bin/sh -vx /opt/local/bin/git-flow feature finish f2

assuming you have a default install. My quick check shows that it's correctly setting $DOT_GIT_DIR from gitflow_load_settings call to rev-parse --git-dir. Maybe there is something interfering with your init setup? Just as a check, I checked both /opt/local/bin/git and /bin/git with rev-parse --git-dir and received the same correct dir result.

[gorticus (Jason Mitchell)]

log capture of git-flow merge commit fail that does not error out creating the .git/.gitflow/MERGE_BASE ref

[philippe.lang@…]

Hi, I cannot explain why, but for me this patch works:

​https://github.com/nvie/gitflow/commit/a7a89cdb13e0022c67fe2cd688708826828a60d6

I applied the patch to /opt/local/bin/gitflow-common.

[gorticus (Jason Mitchell)]

I updated my currently queued git-flow update (ticket:41609) to include subports for

• the better maintained ​AVH Edition,
• ​HubFlow for use w/ GitHub,
• a git-flow-devel that points to ​nvie's develop branch @ ​15aab264

The last option should take care of getting past this DOT_GIT_DIR issue. I believe the AVH Edition is the better choice, if you want to use a gitflow that is maintained.

Ryan: updating the git-flow Portfile w/ the patch in ticket:41609 should address this ticket.

[gorticus (Jason Mitchell)]

Replying to philippe.lang@…:

Hi, I cannot explain why, but for me this patch works:

​https://github.com/nvie/gitflow/commit/a7a89cdb13e0022c67fe2cd688708826828a60d6

I applied the patch to /opt/local/bin/gitflow-common.

Based on the old code, ... > /dev/null 2>&1 will always produce null output. Looks like a bug, and is so acknowledged in the ​commit a7a89cdb you found. If you patch your Portfile w/ the attachment in mentioned in comment:9, you can uninstall git-flow and install git-flow-devel to access the latest develop HEAD, which is approaching 2 yrs old ...

[neverpanic (Clemens Lang)]

r122828, see #41609.