#7836 Merge request shows 0 commits, if upstream has new commits


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.


Tickets: #7830
Tickets: #7848
Tickets: #7882


  • Dave Brondsema

    Dave Brondsema - 2015-02-19

    I think git merge-base looks like a better command to use than log. We'd need to add one repo as a remote into the other. I think it'd be reasonable to add the upstream one to the forked one. I haven't looked into options for Mercurial.

  • Dave Brondsema

    Dave Brondsema - 2015-02-23
    • labels: ux --> ux, sf-current, sf-4
  • Igor Bondarenko

    Igor Bondarenko - 2015-02-24
    • Owner: Anonymous --> Igor Bondarenko
    • Labels: ux, sf-current, sf-4 --> sf-4, 42cc, ux, sf-current
    • Status: open --> in-progress
  • Igor Bondarenko

    Igor Bondarenko - 2015-03-06

    Do we need to update merge request when there are new commits on downstream (source) branch?

    Right now we save HEAD of the source branch as it was at the moment of merge request creation, and show only those commits, but I think it would be nice to update merge request to the latest commits in the source branch. And it might make things simpler for hg (don't sure about that 100%, but seems like it).

    It also would affect [#7830]. We'll need to merge latest commits, instead of relying on saved commit_id, which can be deleted, if we decide that we want this behavior. And change merge instructions also.

    What do you think?



    Tickets: #7830

    • Dave Brondsema

      Dave Brondsema - 2015-03-06

      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: #5993

      • Igor Bondarenko

        Igor Bondarenko - 2015-03-10

        Yeah, I think current behavior makes sense if we can update merge request, but we should make it more obvious to the user that such possibility exists

  • Igor Bondarenko

    Igor Bondarenko - 2015-04-22
    • status: in-progress --> review
  • Heith Seewald

    Heith Seewald - 2015-05-13
    • Reviewer: Heith Seewald
  • Dave Brondsema

    Dave Brondsema - 2015-05-14
    • Reviewer: Heith Seewald --> Dave Brondsema
  • Dave Brondsema

    Dave Brondsema - 2015-05-20
    • status: review --> closed
  • Dave Brondsema

    Dave Brondsema - 2015-06-01
    • labels: sf-4, 42cc, ux, sf-current --> sf-4, 42cc, ux
  • Igor Bondarenko

    Igor Bondarenko - 2015-06-18
    • Milestone: unreleased --> asf_release_1.3.0

Log in to post a comment.