2

I am new to Bitbucket, and I am trying to figure out how I might be able to use rerere for Pull Requests.

As the admin I would like to try to merge in all branches before someone actually tries merging them in with pull requests. If I catch a branch that will cause a merge conflict I can resolve it ahead of time, and save the resolution with rerere. If I could copy my resolutions to the BitBucket server, it theoretically could automatically resolve the conflict.

I have the following issues, though.

  • I do not know where BitBucket does the merges
  • Even if I did, there is no setting that allows for the automatic committing with rerere. (See this answer that will help from the command line)

I am wondering if there is some way to add a hook of some sort to a pull request that can allow me to execute the requisite commands to apply rerere.

Community
  • 1
  • 1
Joseph K. Strauss
  • 4,683
  • 1
  • 23
  • 40

1 Answers1

2

git rerere is better suited on the local side (you fetching and then merging pull request branches in your local clone)

git rerere is not managed by git repo hosting provider (like GitHub or BitBucket), because a pull request is supposed to be merged trivially (fast-forward merge), for the maintainer to quickly integrate the contributions.

If the merge is not trivial, that means the contributor is notified, and has to do a git fetch + git rebase origin/master in his/her local repo, before pushing again on his/her push request branch.
Then the maintainer is notified (again) and can simply click a button to integrate that revised and updated contribution.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Do you have any documentation that a Pull Request is only for fast-forward merges. I was not under that impression. – Joseph K. Strauss Dec 24 '15 at 15:20
  • @JosephK.Strauss If you are in charge of maintaining a project, and you receive 10+ pull request per day, believe me, you will get that impression (that you ought to be able to click "merge this pull request" without any work on your part) *very* quickly ;) – VonC Dec 24 '15 at 16:40
  • The goal of a merge request is to have no merge conflict in order to increase the odds of it being integrated quickly by the maintainer (because all he/she has to do is to click on a button): https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-using-the-github-web-interface – VonC Dec 24 '15 at 16:42
  • I have tried, and BitBucket merges successfully even when it is not a fast-forward, as long as there are no conflicts. If we could get BitBucket to consider rerere's then that would make my job even easier. – Joseph K. Strauss Dec 24 '15 at 16:49
  • I understand, but for rerere to work, you would need to resolve a conflict at least once, and that is a client-side only operation. Hence no rerere on the server side. – VonC Dec 24 '15 at 17:00
  • BitBucket creates a new commit for a merge, something that is normally associated with client-side, so theoretically, I could possibly be able to plug in to that process somehow. – Joseph K. Strauss Dec 24 '15 at 20:38
  • The merge commit is not client or server side dependent: the merge *conflict* resolution is. – VonC Dec 24 '15 at 21:06