Skip to content
Snippets Groups Projects
  1. Oct 16, 2017
    • Matt Harbison's avatar
      subrepo: share instead of clone if the parent repo is shared (issue5675) (BC) · 68e0bcb90357
      Matt Harbison authored
      Previously, only the top level repo was shared, and then any subrepos were
      cloned on demand.  This is problematic because commits to the parent repo would
      write an updated .hgsubstate to the share source, but the corresponding subrepo
      commit would be stuck in the local subrepo.  That would prevent an update in the
      source repo.  We already go to great lengths to avoid having inconsistent repos
      (e.g., `hg push -r rev` will push _everything_ in a subrepo, even if it isn't
      referenced in one of the parent's outgoing commits).  Therefore, this seems like
      a bug fix, and there's no option to get the old behavior.  I can't imagine the
      previous behavior was useful to anybody.
      
      There shouldn't be an issue with svn, since it is centralized.  Maybe --git-dir
      can be used for git subrepos, but I'll leave that to someone more familiar with
      git.
      
      An integer was previously being implicitly returned from commands.share(), which
      caused dispatch() to start crashing when changing over to returning the shared
      repo.  All error paths appear to raise, so this can be hardcoded to success.
      The clone command checks for 'is None' in a similar pattern, but since
      hg.clone() always returns a tuple, that seems wrong?
      
      .. fix:: Issue 5675
      
         Creating a share of a repository with a Mercurial subrepository will now
         share the subrepository.
      
      and
      
      .. bc::
      
         Mercurial subrepositories are now shared instead of cloned when the parent
         repository is shared.  This prevents dangling subrepository references in the
         share source.  Previously shared repositories with cloned subrepositories
         will continue to function unchanged.
      68e0bcb90357
  2. Oct 15, 2017
  3. Oct 16, 2017
  4. Oct 15, 2017
  5. Oct 17, 2017
  6. Oct 16, 2017
  7. Oct 05, 2017
  8. Oct 04, 2017
  9. Oct 16, 2017
  10. Jan 24, 2015
  11. Oct 06, 2017
  12. Oct 15, 2017
    • Pulkit Goyal's avatar
      amend: add a flag `-n/--note` to store note with amend · 530b7361e3a9
      Pulkit Goyal authored
      This patch utilises the functionality added in previous patches and adds a flag
      to amend command in hgext/amend to add a note to the amend. Since the note is
      stored in the obsmarker metadata, this will only be useful when obsmarker
      creation is enabled, otherwise this is no-op.
      
      Not adding releasenotes part as we yet don't have a functionality in core to
      show the note.
      
      Differential Revision: https://phab.mercurial-scm.org/D1095
      530b7361e3a9
    • Pulkit Goyal's avatar
      cmdutil: pass metadata from amend() to cleanupnodes · 5781e0931c16
      Pulkit Goyal authored
      `commit --amend` and amend command in core and extensions rely on
      cmdutil.amend() for amending a commit. So the logic to add a note to amend must
      reside here. This patch assumes that note will be passed in opts dictionary to
      the function and it will be passed to cleanupnodes and then createmarkers to
      store the note in the obsmarker metadata.
      
      After this patch, note can be stored on an amend changeset by passing notes as a
      part of opts to cmdutil.amend().
      
      Differential Revision: https://phab.mercurial-scm.org/D1094
      5781e0931c16
    • Pulkit Goyal's avatar
      scmutil: add capability to cleanupnodes to take obsmarker metadata · 3df59451cdec
      Pulkit Goyal authored
      This patch adds a metadata argument to cleanupnodes() which will be dict and can
      be passed to obsmarker.createmarkers() and can be stored on the obsmarker.
      In cases when obsolescence is not enabled, the metadata argument is useless.
      
      This is a step towards storing a note in amend.
      
      Differential Revision: https://phab.mercurial-scm.org/D1093
      3df59451cdec
  13. Oct 16, 2017
  14. Oct 17, 2017
  15. Oct 16, 2017
  16. Oct 13, 2017
  17. Oct 16, 2017
  18. Sep 19, 2017
    • Pulkit Goyal's avatar
      registrar: add support for storing the type of command in func object · fe987d0b9e1e
      Pulkit Goyal authored
      This patch adds support for storing the type of command which is going to run in
      the func object. For this it does the following:
      
      1) Add three possible values as attributes to the registrar.command class
      2) Add a new argument to registrar.command._doregister function
      3) Add a new attribute cmdtype to the func object
      
      The type of command will be helpful in deciding what level of access on hidden
      commits it can has.
      
      Differential Revision: https://phab.mercurial-scm.org/D736
      fe987d0b9e1e
  19. Oct 16, 2017
  20. Oct 13, 2017
Loading