6

I have been working with git flow a while and now it is time to finish the first release v1.0.0. I am using SourceTree on Windows for that.

When I wanted to finish the release it I got this error:

sh.exe C:\Users\xy\AppData\Local\Atlassian\SourceTree\gitflow_local\gitflow\git-flow release finish -f C:\Users\xy\AppData\Local\Temp\2ffrpxef.20z v1.0.0
Switched to branch 'master'

error: unable to create file component/admin/config.xml (Permission denied)

There were merge conflicts.

Completed with errors, see above.

I have no idea why this error is occuring as there should not be any file permission issues as that never happened before when working in the feature branch.

After the above failed I had basically all my changes from develop in relation to master in my working copy. I have simply dashed all those changes and removed new files and so on. No there are no conflicts present. So I am again ready to finish my release.

Currently develop and the release are on the same stage and of course a lot of commits ahead of master:My current repository

How can I finish my release without running into this issue?

Is there some way to force the current develop/release stage upon master? Basically all the development commits should be applied onto the master branch - so all merge conflicts when they appear I'd like to solve with the development branch version. Is that possible?

hbit
  • 959
  • 2
  • 13
  • 33

3 Answers3

4

I found someone that could help me with the issue and he had the idea that is was related to some other process locking the file.

To verify this I copied my repository somewhere else, opened it with SourceTree and I was able to do the release finish without an issue.

Hence I guess it is related to the file being locked from something.

Although I had suspected my IDE (PHPStorm), I could not pinpoint it as I closed it and then still had the file permission problem. Maybe it is Dropbox (the whole repository is in there), who knows. But now I know at least a work around.

hbit
  • 959
  • 2
  • 13
  • 33
  • Interesting analysis. +1 – VonC Jan 30 '15 at 19:46
  • Inspired by OP, I restart my Windows and it works. Somewhat weird. – gzc Dec 02 '15 at 15:55
  • 1
    I had the same problem when finishing a hotfix. Turns out that the IDE did indeed lock the file. When the file is saved, everything is fine, then Sourcetree switches to master and the IDE notices that the file changes (to the old version in master) and locks I guess. So just closing the IDE might work as well for some people. – Axel Köhler Sep 17 '18 at 11:57
  • 1
    I can confirm in my case it was because VSCode was opened with the project. – Zooly Mar 19 '19 at 13:25
0

As illustrated in issue 107, that error message means the merge cannot complete because of conflict 'see git-flow-release#L225-L240):

  if ! git_is_branch_merged_into "$BRANCH" "$MASTER_BRANCH"; then
    git checkout "$MASTER_BRANCH" || \
      die "Could not check out $MASTER_BRANCH."
    git merge --no-ff "$BRANCH" || \
      die "There were merge conflicts."

That means you need to resolve the merge conflicts, and complete the merge first.

The OP hbit adds

Basically all the development commits should be applied onto the master branch - so all merge conflicts when they appear I'd like to solve with the development branch version.

That is typical of a develop branch rebased on master:

  • rebase means you replay the develop branch on top of master, resolving any conflict in the develop branch
  • rebase means, once the develop branch is on top of master (rebased), a merge to master (done by the git-flow release finish) will be a trivial fast-forward one.
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • As you can see from my screen all of the `feature/...` branch commits went into one commit on the `development` branch which is based on the `master` branch. So I am not sure whether I need a rebase - I sort of would expect that I am at the stage where a `git-flow release finish` would be a fast-forward merge. Can you see what I mean? – hbit Jan 14 '15 at 15:50
0

I guess this error can happen not only if you have modified the permissions but also if you modified the ownership of that file (which CAN lead to permission changes).

I could not get rid of this problem myself so what I did (and worked for me) was something like “hide the skeleton in the closet”. The purpose is to isolate the buggy file into a test branch that you can delete afterwards.

sudo rm badfile.xxx - remove file physically, make sure you have a copy to add it later

git add —all badfile.xxx - mark it as deleted in the stage

git checkout -b some_local_branch_we_ll_never_use - create a new branch before committing

git commit -m "Delete the bad file" - commit with deletion of bad file in the new branch, working directory should be clean

git checkout my_good_old_branch - going back to you working branch and continue with your life…

You can then delete your test branch:

git branch -D some_branch_we_ll_never_use

git status

despina
  • 437
  • 3
  • 13