I am not 100% sure. We have [#5993] about the issue too. My initial thoughts are that automatically updating is the most useful, although it potentially could go wrong in some cases (e.g. if you make your changes on a master branch of a fork, and then make some other changes again on the master branch, those really shouldn't be part of the merge request). It certainly would be good and fine if people always use branches for each merge request.
I kind of like the current behavior (noted in [#5993]) where you can edit and re-save the merge request to update it. Then it is an explicit action that someone needs to take if they have pushed further changes. This functionality is not very obvious now, though. --- ** [tickets:#7836] Merge request shows 0 commits, if upstream has new commits** **Status:** in-progress **Milestone:** unreleased **Labels:** sf-4 42cc ux sf-current **Created:** Wed Feb 18, 2015 11:44 PM UTC by Dave Brondsema **Last Updated:** Fri Mar 06, 2015 09:56 AM UTC **Owner:** Igor Bondarenko A merge request works ok if the downstream (forked) repo has all of the upstream (parent) repo's commits. But if the upstream repo has new commits on it, then the merge request shows 0 commits. This is because `MergeRequest._commits` can't find the upstream HEAD in the forked repo, so the `log()` doesn't work. We should have a smarter technique for finding the list of added commits. We should also have better error handling and message to the user when it can't be found since that'll probably still happen sometimes. --- Sent from forge-allura.apache.org because [email protected] is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
