Skip to content
Snippets Groups Projects
  1. Oct 30, 2013
  2. Oct 23, 2013
  3. Oct 24, 2013
  4. Oct 23, 2013
  5. Oct 14, 2013
    • Pierre-Yves David's avatar
      rebase: preserve active bookmark when not at head (issue3813) · 0f997472
      Pierre-Yves David authored
      Now that the working directory parent is preserved, we can preserve the active
      bookmark too.
      0f997472
    • Pierre-Yves David's avatar
      rebase: preserve working directory parent (BC) · 9c78ed39
      Pierre-Yves David authored
      Prior to this changeset, rebase always left the working directory as a parent of
      the last rebased changeset. The is dubious when, before the rebase, the working
      directory was not a parent of the tip most rebased changeset.
      
      With this changeset, we move the working directory back to its original parent.
      If the original parent was rebased, we use it's successors.
      
      This is a step toward solving issue3813 (rebase loses active bookmark if it's
      not on a head)
      9c78ed39
  6. Oct 01, 2013
  7. Oct 02, 2013
  8. Sep 30, 2013
    • Katsunori FUJIWARA's avatar
      rebase: catch RepoLookupError at restoring rebase state for summary · e7fa36d2
      Katsunori FUJIWARA authored
      Before this patch, "hg summary" may fail, when there is inconsistent
      rebase state: for example, the root of rebase destination revisions
      recorded in rebase state file is already stripped manually.
      
      Mercurial earlier than 2.7 allows users to do anything other than
      starting new rebase, even though current rebase is not finished or
      aborted yet. So, such inconsistent rebase states may be left and
      forgotten in repositories.
      
      This patch catches RepoLookupError at restoring rebase state for
      summary hook, and treat such state as "broken".
    • Katsunori FUJIWARA's avatar
      rebase: catch RepoLookupError at restoring rebase state for abort/continue · 577f4c56
      Katsunori FUJIWARA authored
      Before this patch, "rebase --abort"/"--continue" may fail, when rebase
      state is inconsistent: for example, the root of rebase destination
      revisions recorded in rebase state file is already stripped manually.
      
      Mercurial earlier than 2.7 allows users to do anything other than
      starting new rebase, even though current rebase is not finished or
      aborted yet. So, such inconsistent rebase states may be left and
      forgotten in repositories.
      
      This patch catches RepoLookupError at restoring rebase state for
      abort/continue, and treat such state as "broken".
      577f4c56
  9. Sep 20, 2013
    • Siddharth Agarwal's avatar
      rebase: remove bailifchanged check from pullrebase (BC) · 7805cb80
      Siddharth Agarwal authored
      This saves us a relatively superfluous status check for pull --rebase (if
      rebase runs, it'll check for a clean working directory anyway), and brings hg
      pull --rebase closer to hg pull && hg rebase.
      
      This is a behavior change because pull --rebase with a dirty working directory
      will now abort after performing the pull rather than before.
      7805cb80
  10. Sep 03, 2013
  11. Aug 01, 2013
  12. Jul 25, 2013
  13. Jul 12, 2013
  14. May 14, 2013
  15. Apr 18, 2013
  16. Feb 08, 2013
  17. Mar 12, 2013
  18. Mar 11, 2013
    • Durham Goode's avatar
      rebase: restore active bookmark after rebase --continue · 72412afe
      Durham Goode authored
      When a rebase has conflicts and the user uses rebase --continue, the previously
      active bookmark was not being made active once again. With this change that
      bookmark is made active again, just as if the rebase had never been interrupted.
      
      This changes the rebasestate file format, but should handle old formats correctly.
      Since the file is transient, this is even less of a problem.
      
      Adds a test to verify the new behavior. I manually tested continuing rebases
      with and without an active bookmark, and with and without being on the bookmark
      being rebased.
      72412afe
  19. Feb 10, 2013
  20. Feb 03, 2013
  21. Feb 01, 2013
    • Pierre-Yves David's avatar
      rebase: mention --rev in the help · 0324a1d8
      Pierre-Yves David authored
      This changeset adds a small mention of it in the help to prevent
      confusion. This small addition references online help that is easier to
      update and improve at release time.
      
      Following Wagner Bruna's advice, this is added in a plain new paragraph
      to not invalidate current translation this close to the release.
      0324a1d8
    • Kevin Bullock's avatar
      rebase: mention phases in the help · 9fbeb61b
      Kevin Bullock authored
      Mention that Mercurial helps you not do what you've just been warned not
      to do, with a reference to the 'phases' help topic (not the 'phase'
      command help).
      
      Thanks to Pierre-Yves David <pierre-yves.david@ens-lyon.org> for
      motivating this change and Wagner Bruna
      <wagner.bruna+mercurial@gmail.com> for advising on how to do it in an
      i18n-friendly way.
      9fbeb61b
  22. Jan 31, 2013
  23. Jan 18, 2013
    • Pierre-Yves David's avatar
      rebase: properly handle unrebased revision between rebased one · 7159426c
      Pierre-Yves David authored
      With rebase taking multiple roots it is possible to have revision in the "rebase
      domain" not rebased themself. We do not want rebased revision above them to be
      detached. We want such revision to be rebased on the nearest rebased ancestors.
      This allows to preserve the topology of the rebase set as much a possible
      
      To achieve this we introduce a new state `revignored` which informs
      `defineparents` of the situation.
      
      The test in `test-rebase-obsolete.t` was actually wrote and his now fixed.
      7159426c
    • Pierre-Yves David's avatar
      rebase: lose the comparison to `nullmerge` · c83d36b8
      Pierre-Yves David authored
      For a proper behavior of the `--rev` revision we will need another possible
      state for revision ignored by rebase. We alter the comparison to `nullmerge`
      to match this future lower state too.
      c83d36b8
    • Pierre-Yves David's avatar
      rebase: do not invent successor to skipped changeset · 55aff0c2
      Pierre-Yves David authored
      When rebase results in an empty a changeset it is "skipped" and no related
      changeset is created at all. When we added obsolescence support to rebase (in
      fc2a6114f0a0) it seemed a good idea to use its parent successor as the
      successors for such dropped changesets. (see old version of the altered test).
      This option was chosen because it seems a good way to hint about were the
      dropped changeset "intended" to be. Such hint would have been used by automatic
      evolution mechanism to rebase potential unstable children.
      
      However, field testing of this version are not conclusive. It very often leads
      to the creation of (totally unfounded) evolution divergence. This changeset
      changes this behavior and mark skipped changesets as pruned (obsolete without
      successors). This prevents the issue and seems semantically better probably a
      win for obsolescence reading tool.
      
      See example bellow for details:
      
      User Babar has five changesets of interest:
      - O, its current base of development.
      - U, the new upstream
      - A and C, some development changesets
      - B another development changeset independent from A
      
          O - A - B - C
            \
              U
      
      Babar decides that B is more critical than the A and C and rebase it first
      
        $ hg rebase --rev B --dest U
      
      B is now obsolete (in lower case bellow). Rebase result, B', is its
      successors.(note, C is unstable)
      
          O - A - b - C
            \
              U - B'
      
      Babar is now done with B', and want to rebase the rest of its history:
      
        $ hg rebase --source A --dest B'
      
      
      hg rebase process A, B and C. B is skipped as all its changes are already contained
      in B'.
      
          O - U - B' - A' - C'
      
      Babar have the expected result graph wise, obsolescence marker are as follow:
      
          B -> B' (from first rebase)
          A -> A' (from second rebase)
          C -> C' (from second rebase)
          B -> ?? (from second rebase)
      
      Before this changeset, the last marker is `B -> A'`. This cause two issues:
      
      - This is semantically wrong. B have nothing to do with A'
      - B has now two successors sets: (B',) and (A',). We detect a divergent
        rewriting. The B' and A' are reported as "divergent" to Babar, confusion
        ensues. In addition such divergent situation (divergent changeset are children
        to each other) is tricky to solve.
      
      With this changeset the last marker is `B -> ø`:
      
      - This is semantically better.
      - B has a single successors set (B',)
      
      This scenario is added to the tests suite.
      55aff0c2
  24. Jan 16, 2013
    • Pierre-Yves David's avatar
      rebase: support multiple roots for rebaseset · 100fdc84
      Pierre-Yves David authored
      We have all the necessary mechanism to rebase a set with multiple roots, we only
      needed a proper handling of this case we preparing and concluding the rebase.
      This changeset des that.
      
      Rebase set with multiple root allows some awesome usage of rebase like:
      
      - rebase all your draft on lastest upstream
      
        hg rebase --dest @ --rev 'draft()'
      
      - exclusion of specific changeset during rebase
      
        hg rebase --rev '42:: - author(Babar)'
      
      -  rebase a set of revision were multiple roots are later merged
      
        hg rebase --rev '(18+42)::'
      100fdc84
  25. Jan 15, 2013
  26. Dec 04, 2012
  27. Dec 31, 2012
    • Pierre-Yves David's avatar
      rebase: allow non-head rebase-set when obsolete is enabled · bacf55bd
      Pierre-Yves David authored
      Obsolescence markers can represent this situation just fine. Rebased
      revisions are marked as precursors of the ones create by
      rebase. Unrebased descendants becomes "unstable".
      
      If obsolescence is not enabled we keep the current behavior of
      aborting. This new behavior only applies when obsolete is
      enabled and is subject to future discussion and changes.
      bacf55bd
  28. Dec 18, 2012
Loading