Skip to content
Snippets Groups Projects
  1. Apr 23, 2015
    • Laurent Charignon's avatar
      record: edit patch of newly added files (issue4304) · 8133494a
      Laurent Charignon authored
      I tried to fix this issue in the past and had to revert the fix. This is a
      second attempt without the regression we found with the first one.
      
      record defines special headers (of file) as headers whose hunk are not shown
      to the user for editing, they are used to represent deleted, moved and new
      files. Since we want to authorize editing the patch of newly added file we
      make the newly added file with some content not special anymore. This entails
      that we have to save their content before applying the backup to be able to
      revert it if the patch does not apply properly.
      We reintroduce the test showing that newly added files can be edited and that
      their content is shown to the user.
      8133494a
  2. Apr 22, 2015
  3. Mar 06, 2015
    • Laurent Charignon's avatar
      record: allow editing new files (issue4304) · 79fceed6
      Laurent Charignon authored
      While using the record extension to select changes, the user couldn't see the
      content of newly added files and had to select/reject them based on filename.
      The test is changed accordingly in two places.
      79fceed6
  4. Apr 18, 2014
  5. Dec 18, 2014
    • Eric Sumner's avatar
      bundlerepo: retract phase boundary · e7fcf58a
      Eric Sumner authored
      This patch makes bundrepo retract the phase boundary for new commits to 'draft'
      status, which is consistent with the behavior of 'hg unbundle'.  The old
      behavior was for commits to appear with the same phase as their nearest
      ancestor in the base repository.
      
      This affects several classes of operation:
      
      * Inspecting a bundle with the -B flag
      * Treating a bundle file as a peer (old: everything public, new: everything draft)
      * Incoming command (neither old or new behavior is sensible -- fixed in next patch)
      e7fcf58a
  6. Dec 21, 2014
    • Christian Ebert's avatar
      keyword: handle resolve to either parent · cb9d8454
      Christian Ebert authored
      Merged files are considered modified at commit time even if only 1 parent
      differs. In this case we must use the change context of this parent for
      expansion.
      
      The issue went unnoticed for long because it is only apparent until the next
      update to the merge revision - except in test-keyword where it was always
      staring us in the face.
      cb9d8454
    • Christian Ebert's avatar
      keyword: update test file syntax · bb679344
      Christian Ebert authored
      bb679344
  7. Sep 30, 2014
  8. Jul 26, 2014
  9. Jun 23, 2014
  10. Jun 09, 2014
  11. Jun 05, 2014
    • Katsunori FUJIWARA's avatar
      keyword: suppress keyword expansion while 'hg fetch' for internal merge · 2668a78d
      Katsunori FUJIWARA authored
      Before this patch, 'hg fetch' may cause unexpected conflict, if 'hg
      fetch'-ed changes are located near lines in which keywords are
      embedded, because keywords are substituted with other strings in the
      working directory.
      
      This patch suppresses keyword expansion while 'hg fetch' for internal
      merge by adding 'fetch' to 'restricted' command list like 'merge'.
      
      This patch uses 'hg import' to safely create the new head to be merged
      at succeeding 'hg fetch', because:
      
        - branch of revision #10 is different from one of #11 in 'Test'
          repository, so just 'hg fetch -r 11' doesn't cause merging between
          them
      
          this means the new head should be created manually.
      
        - 'hg import' is easier and safer than 'cat <<EOF' and 'hg commit'
          to replay same changes including special characters like '$'
      
          safeness of 'hg import' with keyword extension is already examined
          in 'test-keyword.t'.
      2668a78d
    • Katsunori FUJIWARA's avatar
      keyword: suppress keyword expansion while 'hg histedit' for internal merge · e22cfd1a
      Katsunori FUJIWARA authored
      Before this patch, 'hg histedit' may cause unexpected conflict, if 'hg
      histedit'-ed changes are located near lines in which keywords are
      embedded, because keywords are substituted with other strings in the
      working directory.
      
      This patch suppresses keyword expansion while 'hg histedit' for
      internal merge by adding 'histedit' to 'restricted' command list like
      'merge'.
      
      Test in this patch just swaps order of revision #13 and #14: this is
      enough to cause internal merge.
      e22cfd1a
    • Katsunori FUJIWARA's avatar
      keyword: suppress keyword expansion while 'hg backout' for internal merge · 5c64c338
      Katsunori FUJIWARA authored
      Before this patch, 'hg backout' may cause unexpected conflict, if 'hg
      backout'-ed changes are located near lines in which keywords are
      embedded, because keywords are substituted with other strings in the
      working directory.
      
      This patch suppresses keyword expansion while 'hg backout' for
      internal merge by adding 'backout' to 'restricted' command list like
      'merge'.
      5c64c338
    • Katsunori FUJIWARA's avatar
      keyword: suppress keyword expansion while 'hg graft' for internal merge · dd5ca1a3
      Katsunori FUJIWARA authored
      Before this patch, 'hg graft' may cause unexpected conflict, if 'hg
      graft'-ed changes are located near lines in which keywords are
      embedded, because keywords are substituted with other strings in the
      working directory.
      
      This patch suppresses keyword expansion while 'hg graft' for internal
      merge by adding 'graft' to 'restricted' command list like 'merge'.
      dd5ca1a3
    • Katsunori FUJIWARA's avatar
      keyword: suppress keyword expansion while 'hg rebase' for internal merge · 65dd65c6
      Katsunori FUJIWARA authored
      Before this patch, 'hg rebase' may cause unexpected conflict, if 'hg
      rebase'-ed changes are located near lines in which keywords are
      embedded, because keywords are substituted with other strings in the
      working directory.
      
      This patch suppresses keyword expansion while 'hg rebase' for internal
      merge by adding 'rebase' to 'restricted' command list like 'merge'.
      
      This patch specifies '--keep' to 'hg rebase', because revision #10 is
      useful also for tests in succeeding patches.
      65dd65c6
    • Katsunori FUJIWARA's avatar
      keyword: suppress keyword expansion while 'hg unshelve' for internal merge · 99f7e5fe
      Katsunori FUJIWARA authored
      Before this patch, 'hg unshelve' may cause unexpected conflict, if 'hg
      unshelve'-ed changes are located near lines in which keywords are
      embedded, because keywords are substituted with other strings in the
      working directory.
      
      This patch suppresses keyword expansion while 'hg unshelve' for
      internal merge by adding 'unshelve' to 'restricted' command list like
      'merge'.
      99f7e5fe
  12. May 26, 2014
    • Pierre-Yves David's avatar
      merge: drop the quotes around commit description · 9c35f3a8
      Pierre-Yves David authored
      We already have a ":" after the user name to denote the start of the
      description. The current usage of quotes around the description is
      problematic as the truncation to 80 chars is likely to drop the
      closing quote. This may confuse syntax coloration in some editors.
      9c35f3a8
  13. May 08, 2014
    • Durham Goode's avatar
      merge: add conflict marker formatter (BC) · 25d5a9ec
      Durham Goode authored
      Adds a conflict marker formatter that can produce custom conflict marker
      descriptions. It can be set via ui.mergemarkertemplate. The old behavior
      can be used still by setting ui.mergemarkers=basic.
      
      The default format is similar to:
      
        {node|short} {tag} {branch} {bookmarks} - {author}: "{desc|firstline}"
      
      And renders as:
      
        contextblahblah
        <<<<<<< local: c7fdd7ce4652 - durham: "Fix broken stuff in my feature branch"
        line from my changes
        =======
        line from the other changes
        >>>>>>> other: a3e55d7f4d38  master - sid0: "This is a commit to master th...
        morecontextblahblah
      25d5a9ec
  14. May 09, 2014
    • Matt Mackall's avatar
      resolve: simplify "finished" message · e4f451c8
      Matt Mackall authored
      The recently introduced message was:
      
        no unresolved files; you may continue your unfinished operation
      
      This had three problems:
      
      - looks a bit like an error message because it's not saying "we've
        just resolved the last file"
      - refers to "unfinished operation", which won't be the case with
        "update" or "merge"
      - introduces semicolons to error messages, which is stylistically
        questionable
      
      I've simplified this to:
      
        no more unresolved files
      
      In the future, if we want to prompt someone to continue a particular operation, we should use
      a hint style:
      
        no more unresolved files
        (use 'hg graft --continue' to finish grafting)
      e4f451c8
  15. Apr 19, 2014
    • Gregory Szorc's avatar
      resolve: print message when no unresolved files remain (issue4214) · 19d6fec6
      Gregory Szorc authored
      When using resolve, users often have to consult with the output of |hg
      resolve -l| to see if any unresolved files remain. This step is tedious
      and adds overhead to resolving.
      
      This patch will notify a user if there are no unresolved files remaining
      after executing |hg resolve|::
      
          no unresolved files; you may continue your unfinished operation
      
      The patch stops short of telling the user exactly what command should be
      executed to continue the unfinished operation. That is because this
      information is not currently captured anywhere. This would make a
      compelling follow-up feature.
      19d6fec6
  16. Feb 08, 2013
    • kiilerix's avatar
      export: show 'Date' header in a format that also is readable for humans · 76b69ccc
      kiilerix authored
      'export' is the official export format and used by patchbomb, but it would only
      show date as a timestamp that most humans might find it hard to relate to. It
      would be very convenient when reviewing a patch to be able to see what
      timestamp the patch will end up with.
      
      Mercurial has always used util.parsedate for parsing these headers. It can
      handle 'all' date formats, so we could just as well use a readable one.
      
      'export' will now use the format used by 'log' - which is the format described
      as 'Unix date format' in the templating help. We assume that all parsers of '#
      HG changeset patch'es can handle that.
      76b69ccc
  17. Jan 21, 2013
  18. Jan 15, 2013
    • Pierre-Yves David's avatar
      destroyed: drop complex branchcache rebuilt logic · 904b7109
      Pierre-Yves David authored
      The strip code used a trick to lower the cost of branchcache update after a
      strip. However is less necessary since we have branchcache collaboration.
      Invalid branchcache are likely to be cheaply rebuilt again a near subset of the
      repo.
      
      Moreover, this trick would need update to be relevant in the now filtered
      repository world. It currently update the unfiltered branchcache that few people
      cares about. Make it smarter on that aspect would need complexes update of the
      calling logic
      
      
      So this mechanism is:
      - Arguably needed,
      - Currently irrelevant,
      - Hard to update
      and I'm dropping it.
      
      We now update the branchcache in all case by courtesy of the read only reader.
      
      This changeset have a few expected impact on the testsuite are different cache
      are updated.
      904b7109
    • Pierre-Yves David's avatar
      branchmap: update cache of 'unserved' filter on new changesets · 50104481
      Pierre-Yves David authored
      The `commitctx` and `addchangegroup` methods of repo upgrade branchcache after
      completion. This behavior aims to keep the branchcache in sync for read only
      process as hgweb. See ee317dbfb9d0 for details.
      
      Since changelog filtering is used, those calls only update the cache for unfiltered repo.
      One of no interest for typical read only process like hgweb.
      
      Note: By chance in basic case, `repo.unfiltered() == repo.filtered('unserved')`
      
      This changesets have the "unserved" cache updated instead. I think this is the
      only cache that matter for hgweb.
      
      We could imagine updating all possible branchcaches instead but:
      - I'm not sure it would have any benefit impact. It may even increase the odd of
        all cache being invalidated.
      - This is more complicated change.
      
      So I'm going for updating a single cache only which is already better that
      updating a cache nobody cares about.
      
      This changeset have a few expected impact on the testsuite are different cache
      are updated.
      50104481
  19. Jan 13, 2013
    • Kevin Bullock's avatar
      filtering: rename filters to their antonyms · f3b21beb
      Kevin Bullock authored
      Now that changelog filtering is in place, it's become evident that
      naming the filters according to the set of revs _not_ included in the
      filtered changelog is confusing. This is especially evident in the
      collaborative branch cache scheme.
      
      This changes the names of the filters to reflect the revs that _are_
      included:
      
        hidden -> visible
        unserved -> served
        mutable -> immutable
        impactable -> base
      
      repoview.filteredrevs is renamed to filterrevs, so that callers read a
      bit more sensibly, e.g.:
      
        filterrevs('visible') # filter revs according to what's visible
      f3b21beb
  20. Jan 10, 2013
  21. Jan 08, 2013
  22. Jan 02, 2013
    • Pierre-Yves David's avatar
      clfilter: add mutable filtering · aff706b3
      Pierre-Yves David authored
      It filters all mutable changesets, leaving only public changeset unfiltered.
      This filtering set is expected to be much more stable that the previous one as
      public changeset are unlikely to disapear.
      
      The only official use of this filter is for branchcache.
      aff706b3
  23. Jan 07, 2013
    • Pierre-Yves David's avatar
      branchmap: allow to use cache of subset · a55b0688
      Pierre-Yves David authored
      Filtered repository are *subset* of unfiltered repository. This means that a
      filtered branchmap could be use to compute the unfiltered version.
      
      And filtered version happen to be subset of each other:
      - "all() - unserved()" is a subset of "all() - hidden()"
      - "all() - hidden()" is a subset of "all()"
      
      This means that branchmap with "unfiltered" filter can be used as a base for
      "hidden" branchmap that itself could be used as a base for unfiltered
      branchmap.
      
         unserved < hidden < None
      
      This changeset implements this mechanism. If the on disk branchcache is not valid
      we use the branchcache of the nearest subset as base instead of computing it from
      scratch. Such fallback can be cascaded multiple time is necessary.
      
      Note that both "hidden" and "unserved" set are a bit volatile. We will add more
      stable filtering in next changesets.
      
      This changeset enables collaboration between no filtering and "unserved"
      filtering. Fixing performance regression introduced by 47f00b0de337
      a55b0688
  24. Dec 21, 2012
    • Idan Kamara's avatar
      localrepo: filter unknown nodes from the phasecache on destroyed · 082d6929
      Idan Kamara authored
      When commit is followed by strip (qrefresh), phasecache contains nodes that were
      removed from the changelog. Since phasecache is filecached with .hg/store/phaseroots
      which doesn't change as a result of stripping, we have to filter it manually.
      
      If we don't write it immediately, the next time it is read from disk the nodes
      will be filtered again. That's what happened before, but there's no reason not
      to write it immediately.
      
      The change in test-keyword.t is caused by the above.
      082d6929
  25. Dec 27, 2012
  26. Dec 24, 2012
    • Pierre-Yves David's avatar
      branchmap: move validity logic in the object itself · db25bf1d
      Pierre-Yves David authored
      In several place, We check if a branchcache is still valid regarding the current
      state of the repository. This changeset puts this logic in a method of the object
      that can be reused when necessary.
      
      A branch map is considered valid whenever it is up to date or a strict subset of
      the repository state.
      
      The change will help making branchcache aware of filtered revision.
      
      The change in keyword is expected. the branch cache is actually invalid after
      the amend. The previous check did not detected it.
      db25bf1d
  27. Oct 18, 2012
    • Pierre-Yves David's avatar
      amend: add noise in extra to avoid creating obsolescence cycle (issue3664) · a8aba292
      Pierre-Yves David authored
      Obsolescence cycle are bad and should be avoided as much as possible. The
      current amend implemented touch changeset meta data as few as possible. This
      make is easy for amend to result in the same node than a precursors. We add some
      deterministic noise in extra to avoid this. In practice, the hex of the amended
      changeset is stored in 'amend_source' extra key.
      a8aba292
  28. Sep 11, 2012
  29. Aug 17, 2012
  30. Aug 15, 2012
  31. Aug 08, 2012
  32. Jul 03, 2012
Loading