Commit graph

10 commits

Author SHA1 Message Date
Oswaldo Ferreira
1f54c9216f Reduce method calls while evaluating Projects::MergeRequestsController#show.json 2017-10-04 00:09:48 -03:00
Robert Speicher
72a7b30c9f Change all :empty_project to :project 2017-08-02 17:47:31 -04:00
Robert Speicher
9513bd18c4 Ensure all project factories use :repository trait or :empty_project 2017-08-01 14:51:52 -04:00
Clement Ho
531157f5b4 Fix spec name grammer 2017-07-12 10:02:53 -05:00
Clement Ho
6eeb638434 Make commits behind text a link to the target branch commits page 2017-07-11 11:49:22 -05:00
Clement Ho
09193a4fe1 Convert target branch link to use tree 2017-07-11 09:48:59 -05:00
Clement Ho
9e4e1afb4a MR branch link now links to tree instead of commits 2017-07-10 14:55:13 -05:00
Adam Niedzielski
4bfd06e60e Display issue state in issue links section of merge request widget 2017-06-09 10:21:56 +02:00
Sean McGivern
ad2bfeb857 Fix conflict resolution from corrupted upstream
I don't know why this happens exactly, but given an upstream and fork repository
from a customer, both of which required GC, resolving conflicts would corrupt
the fork so badly that it couldn't be cloned.

This isn't a perfect fix for that case, because the MR may still need to be
merged manually, but it does ensure that the repository is at least usable.

My best guess is that when we generate the index for the conflict
resolution (which we previously did in the target project), we obtain a
reference to an OID that doesn't exist in the source, even though we already
fetch the refs from the target into the source.

Explicitly setting the source project as the place to get the merge index from
seems to prevent repository corruption in this way.
2017-05-12 20:47:51 +01:00
Fatih Acet
0151325dac Merge request widget redesign 2017-05-09 04:15:34 +00:00