D24: rebase: remove revprecursor and revpruned states (BC)

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.


  This broke some of our internal tests. We do something like this:
  
  Start with a patch on top of upstream @:
  o A
  
  |
  |
  
  @
  
  Commit A gets sent for review and landed. The user then does "hg pull":
  
  o A'
  
  |
  | @ A obsolete |
  | /            |
  |
  
  o
  
  What our tests (and most of our users) actually do is "hg pull --rebase". Before this patch, that would result in:
  
  @ A'
  
  |
  |
  
  o
  
  After this patch, the update doesn't happen, so the user stays in the state in the graph above. I suppose the same would happen if there were commits on top of A. Expecting the update to happen seems reasonable to me, but I also see your point.
  
  Here's another argument for the old behavior. Let's say there was no pull involved and we instead had this:
  
  o D
  
  |
  |
  
  o B'
  
  |
  | o C |
  |     |
  | x B |
  |     |
  | o A |
  | /   |
  |
  
  o
  
  Then "hg rebase -d D -b C". If that command was run from A or C, one would end up on A' or C'. If it was run from B, it seems reasonable that one would end up on A', as one would before this patch, I believe.
  
  So what do you think? Should we back out this patch?

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D24

To: quark, durin42, #hg-reviewers
Cc: martinvonz, durin42, mercurial-devel