1

So, suppose I have a bookmark with some feature implemented, so the log (hg graph --style compact -G) is like:

o  3[tip]:1   4fa205099913   2014-07-28 13:37 +0300   shabunc
|    default commit C
|
| @  2[feature]   d3c4f62b33ca   2014-07-28 13:36 +0300   shabunc
|/     feature commit A
|
o  1   a06864113f47   2014-07-28 13:35 +0300   shabunc
|    default commit B
|
o  0   d746532dac10   2014-07-28 13:35 +0300   shabunc
     default commit A

In rhodecode I can choose the bookmark I want to create a PR about. Here's submit form to give you idea what I'm talking about:

enter image description here

In this case, there will be one changeset int feature-based pull request (d3c4f62b33ca). This is predictable and intuitive.

But now supposed you've worked on some feature under the bookmark but remote repo had not been changed since, so you have this log graph:

@  2[tip][feature]   d3c4f62b33ca   2014-07-28 13:36 +0300   shabunc
|    feature commit A
|
o  1   a06864113f47   2014-07-28 13:35 +0300   shabunc
|    default commit B
|
o  0   d746532dac10   2014-07-28 13:35 +0300   shabunc
     default commit A

This is a well-known mercurial behavior - new head is not created until no new changes had been introduced even after the bookmark creation.

But now, because no head yet had been created, an attempt to create PR based on feature will end up with having all three commits in the pull request. This is not something we actually want.

So, the question is - in Rhodecode, how to add to pull request changes that had been introduced after the bookmark creation but before new head has been created? My first thought was that it it something more mercurial specific, but Lasse V. Karlsen (see the discussion below) pointed out that this most probably is RhodeCode-specific issue.

shabunc
  • 23,119
  • 19
  • 77
  • 102
  • I don't understand this question. That last history, that's local I take it, but what does the history look like in the central repository you want to add a pull request into? If neither 0, 1 or 2, is in the central repo then you absolutely need to push/pull all of those into it. Can you elaborate a bit more on the scenario here? – Lasse V. Karlsen Jul 28 '14 at 11:12
  • @LasseV.Karlsen this is how it looks like in remote repo. So, when I'm creating a PR pointing specific bookmark it adds all changesets in the branch to which this bookmarks point. But if there was not changes (so there's still one head) pointing the bookmark will lead to inclusion of all changesest in the branch. Had added an screenshot in attempt to make the question more clear – shabunc Jul 28 '14 at 11:35
  • Then I think this might be a rhodecode issue, since pull/push should only consider the changesets that are missing in the target repository. If some of the changesets in that history is already in the target history, then those will not be pushed, but you're saying that if you create a pull request (which is not built into Mercurial), they are all included. This must thus be an issue with the pull request functionality, which as I said, is not native to Mercurial. – Lasse V. Karlsen Jul 28 '14 at 11:44
  • However, to be honest, does it matter? For the target to pull your feature changeset, it will need those below if it doesn't already have them. When you say that the pull request *having all three* of those changesets, does the pull request system list the changesets or just show them, actually only recording the topmost changeset? – Lasse V. Karlsen Jul 28 '14 at 11:45
  • @LasseV.Karlsen, true, it matters only from the point of usability - it won't break repo in any way, it's just that reviewing all the changes introduced can become a nightmare. – shabunc Jul 28 '14 at 11:50
  • It sounds to me as rhodecode doesn't consider the current state of the target repository. It should be able to do a `hg outgoing -r bookmark` to get a list of changesets that would have to be pushed in order to bring that bookmark into the target repository, but it sounds like it doesn't, instead having code that only looks at the source repository and tries to determine which bits might be necessary from that. – Lasse V. Karlsen Jul 28 '14 at 11:53
  • @LasseV.Karlsen looks like you are right. – shabunc Jul 28 '14 at 12:10

0 Answers0