Add link on commit page to merge request that introduced that commit

We can now do this relatively easily, since every MR is copied to refs/merge-requests/:iid/head, and we already have the list of branches in which a commit occurs. We can see if any refs like that are in that list, parse the IID out of there, look up the MR by IID, and link to it.

API

Design

uses the icon from https://gitlab.com/gitlab-org/gitlab-ce/issues/29584

icon-merge-v2.svg

Note: This however needs backend support as described https://gitlab.com/gitlab-org/gitlab-ce/issues/2383#note_26341393

for the idea, still don't quite understand the methodology.

mentioned in issue #18967 (closed)

@rspeicher see this link: https://help.github.com/articles/checking-out-pull-requests-locally/
and perhaps https://gist.github.com/piscisaureus/3342247

Added ~480950 ~14213 ~13921 labels

This would be so useful!

Mentioned in issue #18967 (closed)

mentioned in issue #28953 (closed)

/cc @mydigitalself

mentioned in issue #28956 (closed)

Just started using Gitlab on my new project and this is the first feature I realized I used quite a bit from Github. Would love to see this!

Where should that link link be placed?
What a style should it have?

/cc @tauriedavis

@blackst0ne I think something in the .info-well similar to the link from a Job:

Maybe something like:

Here is a quick job.

I'd like to have ~"UX ready" before I take this issue to the WIP state.

@dimitrieh Thoughts here for @blackst0ne?

added ~19492 label

@blackst0ne this is awesome!

can you make it look like this:

uses the icon from https://gitlab.com/gitlab-org/gitlab-ce/issues/29584

icon-merge-v2.svg

added info the issue body

added ~127616 ~974571 and removed ~19492 labels

if 1 merge request, please make it 1 merge request !2093 (so its not plural)

@blackst0ne i will assign it to you

assigned to @blackst0ne

I like this latest UX mockup, just what I was expecting!

However, it could be on the same line as parents, and we could save some vertical space.

@dimitrieh, great job!
I have a few questions:

1. What should it look like if no MRs found?
2. Is it worth to save some vertical space and move MR info to the same line as branches info? I'm not sure if it's going to be usable when there are many branches and/or merge requests on the same line.

it's funny, i found this in some old mockup i made a while back:

it has the added benefit of showing us the Merge Request name.. which can, i think, instantly give a better sense of context to the current commit you are looking at. Or would it be enough to have this information in the tooltip? What do you think @blackst0ne @elijahlynn ?

If we take a peek at how GH does this: (they only show one branch at most btw... even if the commit lives in another branch as well, which still exists)

@blackst0ne

1. don't show the line ;)
2. Let's figure this out:

After i know your thoughts about the thing mentioned above.. we could go various ways:

• just do the proposed design from https://gitlab.com/gitlab-org/gitlab-ce/issues/2383#note_26073897 (although i feel branches should be more connected with the merge request mentions)
• put everything on 1 line somehow (problem with this is that we only show multiple branches on a button press .. also the amount of branches can increase by a lot (if the commit is older .... having this information in there be lost.. would be a shame i think... even for commits that have long be merged, as you would like to know that context of the commit)
  • possible mockup for that could be (moving the branches with the MR's of which this commit actually is part of) out of the "rest collection", so no button press is needed:
  • or
  • or (less good imo)
• move the branches from parent commit line, to its own line, where we'll also show the merge requests.
  • possible mockup (inspired by previous point):
• keep mr's to a line on itself and provide the titles instantly (not on tooltip)
  • (most of the time, just 1 mr will be mentioned...)

Would love some thoughts :)

I personally most often want to find merge requests where a commit was introduced.
So I like the last mockup (MRs on a separate line).
With titles it's more readable (goodbay robots, welcome humans ), but less consistent with other parts of the product (links to MR in notes, etc).

@dimitrieh

don't show the line ;)

If the line is not shown, how do we know it's not a bug, but there are just no related merge requests found?

mentioned in issue #28982 (moved)

@filipa @smcgivern which one does make sense to you?

If the line is not shown, how do we know it's not a bug, but there are just no related merge requests found?

@blackst0ne If the product is working correctly (like 95%) the user should not want to expect a merge request to be there. It can simply come to expect that there is no attached merge request if it isn't stated. If we were to display all things that aren't there.. we had to display a lot of things in a lot of places

@dimitrieh I like the second one

I'm not sure the description is accurate, though.

@DouweM don't we only have the refs you mention for commits that were the HEAD of an MR version? What about other commits introduced by a push?

So, which mockup is final?

@blackst0ne I don't think this is ready to go just yet. We also can't use the MR's source branch, because you can have multiple MRs with the same source branch (at different times).

I think ideally we would have a join table between commits and MRs, instead of serialising the commits in MR versions, but I'm not sure if it's practical to backfill that.

@smcgivern, so what are we going to do with it?

mentioned in issue #28037 (closed)

As a note on the MR refs, refs/merge-requests/*/head, I noticed they aren't always in place, https://gitlab.com/gitlab-org/gitlab-ce/issues/28037

@dimitrieh I like this solution:

keep mr's to a line on itself and provide the titles instantly (not on tooltip) https://gitlab.com/gitlab-org/gitlab-ce/uploads/9ee10d30b42fb342bf751e110b4ddb76/image.png

@MadLittleMods is that the same as is described here https://gitlab.com/gitlab-org/gitlab-ce/issues/28982 ?

@blackst0ne let's go with

reasoning: Most of the time, there will be a low amount of MR's + it can flow if it needs to. I think the titles in this case make most sense to be written out.. as to show immediate sense of context to the user.. as a commit on itself doesn't say much. Plus We got 3 different people, liking the same mockup

I will update the issue description

@DouweM this apparently needs backend to work correctly. Can we get that in? also see https://gitlab.com/gitlab-org/gitlab-ce/issues/2383#note_26282030

cc: @blackst0ne

added ~901060 label

mentioned in issue #30224 (closed)

@blackst0ne I think we should do https://gitlab.com/gitlab-org/gitlab-ce/issues/30224 so that we can have that information.

removed assignee

mentioned in issue #30664 (closed)

We definitely need more backend work here, it's not as easy as it seems to go from a commit SHA to an MR, even if we have the refs/merge-requests/:iid/head branches, because you want the MR that introduced a commit, not just any MR which contains it.

The approach currently used in the build page to get a merge request that introduced a commit /app/models/ci/build.rb#L205-215 is:

• Get all merge requests that match source branch & project id ordered by id asc.
• Iterate over st_commits foreach MR and return the first one have have an element with id equal to commit sha.

Is there a reason this approach won't work in this case (other than performance) ?

@victorwu see https://gitlab.com/gitlab-org/gitlab-ce/issues/2383#note_27216006

mentioned in issue #19940 (closed)

mentioned in issue #33578 (closed)

mentioned in issue #24098 (closed)

Workaround for Gitlabber (Because I needed now)

git fetch origin
git log --graph
# Find sha
# Find merged sha into master from the commit
# Check a comment of the merged sha. MR id is included in the comment.
# Access https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/<input the MR id>

I want this feature badly sometimes.

@dosuken123 This is what I use:

git config --global alias.merge-commit '!git rev-list $1..HEAD --ancestry-path --merges | tail -n 1 | xargs git show'

(https://gitlab.com/gitlab-org/gitlab-ce/issues/24098)

@winh Thanks. This is great. On my computer, this worked instead of it.

[alias]
        merge-commit = "!f() { git rev-list $1..HEAD --ancestry-path --merges | tail -n 1 | xargs git show; }; f"

It seems need to be wrapped by !f()

@winh @dosuken123 That's great! We can get rid of the tail part and just use -1 with git:

git rev-list $1..HEAD --ancestry-path --merges -1 | xargs git show

A customer expressed interest in this feature at https://gitlab.zendesk.com/agent/tickets/81619.

added customer label

mentioned in merge request !13713 (merged)

changed milestone to %10.0

added Community contribution label

added Plan [DEPRECATED] label

assigned to @hiroponz

mentioned in issue #35521 (moved)

marked #34640 (closed) as a duplicate of this issue

mentioned in issue #34640 (closed)

changed milestone to %10.1

changed milestone to %10.2

I would like to upvote this. We are working on the software for automotive industry and we need to have 2-way traceability (a) from issue to MR (where e.g. CI happens) to code in master and b) from code in master back to MR and issue.

This is practically a deal breaker for us and we would really need to have it implemented.

marked this issue as related to #28037 (closed)

@victorwu is it known that backend is needed for this? see https://gitlab.com/gitlab-org/gitlab-ce/issues/2383#note_27216006

Moving this into 10.3 since it is being worked on now in the 10.3 cycle.

changed milestone to %10.3

changed milestone to %10.4

changed milestone to %10.5

closed via commit 9978602d

mentioned in issue #42118 (moved)

mentioned in merge request !16994 (merged)

mentioned in issue #41437 (closed)

mentioned in issue #44724 (moved)

mentioned in issue #47520 (moved)

added devopsplan label

mentioned in issue gitlab#31708 (closed)

mentioned in issue gitlab#332536 (closed)

marked this issue as related to gitlab#332536 (closed)

marked this issue as related to gitlab#294257

mentioned in issue gitlab#294257