Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't delete branch after Pull Request is granted #2245

Closed
2 of 7 tasks
DerMolly opened this issue Aug 2, 2017 · 11 comments · Fixed by #2250
Closed
2 of 7 tasks

Can't delete branch after Pull Request is granted #2245

DerMolly opened this issue Aug 2, 2017 · 11 comments · Fixed by #2250
Labels
Milestone

Comments

@DerMolly
Copy link

DerMolly commented Aug 2, 2017

  • Gitea version (or commit ref): bbe6aa3
  • Git version: 2.1.4
  • Operating system: Debian 8.9
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

I'm using gitea at work and one colleague really want's to merge his own branches via PRs into master, which totally works until gitea suggests to delete the branch afterwards. That always fails.

When I tested it on try.gitea.io it worked. Is this a bug in the software which was fixed by a commit between bbe6aa3 and dde0052 or do I need to configure something differently?

@lafriks
Copy link
Member

lafriks commented Aug 2, 2017

Does branch name contains /?

@DerMolly
Copy link
Author

DerMolly commented Aug 2, 2017

no but - and _

@DerMolly
Copy link
Author

DerMolly commented Aug 2, 2017

also tried a simple branch name test
same result

@philfry
Copy link
Contributor

philfry commented Aug 2, 2017

Had a similar problem with a centos7 default installation which shipped an older git version.

git 1.8.3.1 does not support force deleting branches. I suspect same goes for 2.1.4.
Gitea tries the following call when deleting a branch:

execve("/usr/bin/git", ["git", "branch", "-d", "-f", "mybranch"], [/* 7 vars */]) = 0

which results in logs like these:

[.../runtime/asm_amd64.s:514 call32()] [E] DeleteBranch: exit status 129 - usage: git branch [options] [-r | -a] [--merged | --no-merged]

Possible workaround: upgrade git. Anyways, please check your gitea logs for errors.

@lafriks lafriks added type/bug issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail labels Aug 2, 2017
@lafriks lafriks added this to the 1.x.x milestone Aug 2, 2017
@lafriks
Copy link
Member

lafriks commented Aug 2, 2017

@Deruser can you verify that git version is the problem?

@DerMolly
Copy link
Author

DerMolly commented Aug 2, 2017

Yes updating to git 2.11.0 via jessie-backports fixed the problem.
Thanks

@DerMolly DerMolly closed this as completed Aug 2, 2017
@DerMolly
Copy link
Author

DerMolly commented Aug 2, 2017

@philfry btw. thanks for the tipp, but the gitea logs did not contain such an error. Which logging level do you use?

@lunny
Copy link
Member

lunny commented Aug 2, 2017

So should we require git version of v2.11.0? It seems not a good idea.

@philfry
Copy link
Contributor

philfry commented Aug 2, 2017

@Deruser "info", usually.
@lunny no, it would be easier to use git branch -D instead. -D is understood by older git versions and expands to -d -f in more recent versions.
git 1.8.3.1:

-D Delete a branch irrespective of its merged status.

git 2.13.4:

-D Shortcut for --delete --force.
-f, --force
           Reset <branchname> to <startpoint> if <branchname> exists already.
           Without -f git branch refuses to change an existing branch. In
           combination with -d (or --delete), allow deleting the branch
           irrespective of its merged status. In combination with -m (or
           --move), allow renaming the branch even if the new branch name
           already exists.

@lafriks lafriks reopened this Aug 2, 2017
@lafriks lafriks removed the issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail label Aug 2, 2017
@lafriks lafriks modified the milestones: 1.2.0, 1.x.x Aug 2, 2017
@lafriks
Copy link
Member

lafriks commented Aug 2, 2017

I have created PR to support also older git versions

@lunny
Copy link
Member

lunny commented Aug 3, 2017

@lafriks You have to update the vendor

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
4 participants