Skip to content
Snippets Groups Projects
  1. Oct 15, 2014
  2. Oct 13, 2014
  3. Oct 15, 2014
  4. Oct 14, 2014
  5. Oct 10, 2014
  6. Oct 12, 2014
  7. Oct 13, 2014
  8. Oct 12, 2014
    • Pierre-Yves David's avatar
      pull: use `stepsdone` instead of `todosteps` · 92bf9abc4deb
      Pierre-Yves David authored
      The push process uses a `stepsdone` attribute instead of a `todosteps` one (with
      the logic swapped). We unify the two process by picking the `stepsdone` version.
      I feel like `stepsdone` better fits extensions that would want to extend the push
      exchange process.
      92bf9abc4deb
  9. Sep 27, 2014
    • Pierre-Yves David's avatar
      pull: make discovery phase extensible · dae236906fb2
      Pierre-Yves David authored
      We apply the same approach as for push and make the discovery extensible. There
      is only one user in core right now, but we already know we'll need something
      smarter for obsmarkers. In fact the evolve extension could use this to cleanly
      extend discovery.
      
      The main motivation for this change is consistency between push and pull.
      dae236906fb2
  10. Oct 14, 2014
  11. Sep 03, 2014
    • Mike Edgar's avatar
      revlog: support importing censored file revision tombstones · 8a096d4d0862
      Mike Edgar authored
      This change allows a revision log to not fail integrity checks when applying a
      changegroup delta (eg from a bundle) results in a censored file tombstone. The
      tombstone is inserted as-is, so future integrity verification will observe the
      tombstone. Deltas based on the tombstone will also remain correct.
      
      The new code path is encountered for *exactly* the cases where _addrevision is
      importing a tombstone from a changegroup. When committing a file containing
      the "magic" tombstone text, the "text" parameter will be non-empty and the
      checkhash call is not executed (and when committing, the node will be computed
      to match the "magic" tombstone text).
      8a096d4d0862
  12. Oct 14, 2014
  13. Oct 08, 2014
  14. Oct 03, 2014
  15. Oct 12, 2014
  16. Oct 03, 2014
    • Martin von Zweigbergk's avatar
      summary: make status code more readable · 2d0b60b5abc0
      Martin von Zweigbergk authored
      In commands.summary(), we currently zip a list of labels with a list
      of statuses. This means the order of the status list has to match the
      list of the labels, which in turn means the status elements have to be
      inserted into specific places in the list. Let's instead group the
      labels and status data we want to display in a single list of pairs.
      2d0b60b5abc0
  17. Oct 05, 2014
  18. Oct 04, 2014
  19. Oct 03, 2014
  20. Oct 04, 2014
  21. Oct 03, 2014
  22. Oct 05, 2014
  23. Oct 10, 2014
  24. Oct 14, 2014
  25. Oct 10, 2014
    • Martin von Zweigbergk's avatar
      status: create class for status lists · cb4449921a1d
      Martin von Zweigbergk authored
      Callers of various status() methods (on dirstate, context, repo) get a
      tuple of 7 elements, where each element is a list of files. This
      results in lots of uses of indexes where names would be much more
      readable. For example, "status.ignored" seems clearer than "status[4]"
      [1]. So, let's introduce a simple named tuple containing the 7 status
      fields: modified, added, removed, deleted, unknown, ignored, clean.
      
      This patch introduces the class and updates the status methods to
      return instances of it. Later patches will update the callers.
      
       [1] Did you even notice that it should have been "status[5]"?
      
      (tweaked by mpm to introduce the class in scmutil and only change one user)
      cb4449921a1d
  26. Oct 04, 2014
    • Martin von Zweigbergk's avatar
      lfutil: avoid creating unnecessary copy of status tuple · 3b8e6c095239
      Martin von Zweigbergk authored
      In lfdirstatestatus(), the status tuple gets deconstructed, the lists
      get updated, and then an identical status tuple gets created and
      returned. Change it so we simply return the original tuple.
      3b8e6c095239
    • Martin von Zweigbergk's avatar
      dirstate: separate 'lookup' status field from others · 509e2cbee679
      Martin von Zweigbergk authored
      The status tuple returned from dirstate.status() has an additional
      field compared to the other status tuples: lookup/unsure. This field
      is just an optimization and not something most callers care about
      (they want the resolved value of 'modified' or 'clean'). To prepare
      for a single future status type, let's separate out the 'lookup' field
      from the rest by having dirstate.status() return a pair: (lookup,
      status).
      509e2cbee679
  27. Oct 13, 2014
Loading