merge request showing wrong commits

[Brenda Wallace]

i created branch ((0.8.x-pginstaller) and a merge request, and it all
looked good.
http://gitorious.org/laconica/mainline/merge_requests/886

I then made a 2nd branch (0.8.x-pgfixes) and made a 2nd merge request
for a different logical set of changes
http://gitorious.org/laconica/mainline/merge_requests/887

However, the first merge request has changed inexplicitly - it still
shows the correct branch name, but the commits it is listing on the
gitorious webpage are not commits present on the branch. It's showing
commits from the second branch.

I've checked with a fresh clone, git log and some grep - those commits
in MR886 are not on 0.8.x-pginstaller branch at all , and yet they
show on that merge request page for that branch. The page was
initially correct after creation but now shows only commits from the
2nd branch (0.8.x-pgfixes)

[Brenda Wallace]

I've checked again now - and now it has swapped.
Both merge request now show only the commits from 0.8.x-pginstaller branch.
Previously both MRs showed only the commits from 0.8.x-pgfixes branch.

--
www.br3nda.com
www.coffee.geek.nz
"Support living artists - the dead ones don't need it." - Collette Rene Fergus

[Marius Mårnes Mathiesen]

Brenda,
First of all: thanks for a very thorough explanation of the bug, this was a great help in resolving the issue!

As Johan mentioned on the blog yesterday (http://blog.gitorious.org/2009/07/15/new-merge-request-functionality/) the merge requests have undergone some substantial changes lately. The merge requests now actually reside as hidden refs in the target repository: we calculate the merge base between the source and target repositories and save this in the merge requests; then push the latest commit that are selected to the before mentioned ref - this way it's a lot easier for Git to track the commits involved in the merge request (it's simply the commits between the merge base and the ending commit in the merge request in the target repository). Additionally, we can do fancy stuff like versioning the merge requests, enabling users to make changes to merge requests.

We cache the commits for a merge request in Memcached, using a key. Unfortunately, the key we used in the cache wasn't unique, which in your case means the two merge requests you submitted had the same cache key. So when you created the second merge request, the two had the same set of commits in the cache. We fixed this issue now, and your merge requests seem to be okay. And of course no data has been lost, this was just a GUI issue.

Sorry for the inconvenience and again thanks for your feedback.

Regards,
- Marius