Skip to content
Snippets Groups Projects
  1. Feb 22, 2025
  2. May 02, 2022
    • Raphaël Gomès's avatar
      verify: also check dirstate · c84844cd523a
      Raphaël Gomès authored
      The dirstate already is capable of verifying its integrity (although v2
      features are not yet checked), let's run that code in `hg verify`.
      c84844cd523a
  3. Jan 11, 2022
  4. Dec 08, 2021
  5. Nov 10, 2021
  6. Oct 19, 2021
    • Pierre-Yves David's avatar
      dirstate-v2: freeze the on-disk format · bf11ff22a9af
      Pierre-Yves David authored
      It seems the format as reached a good balance. With a core of new capabilities
      that motivated it initially and enough new feature and room for future
      improvement to be a clear progress we can set a milestone for.
      
      Having the format frozen will help the feature to get real life testing, outside
      of the test suite.
      
      The feature itself stay experimental but the config gains a new name to avoid
      people enable non-frozen version by default.
      
      If too many bugs are reported during the RC we might move the format back to
      experimental and drop its support in future version (in favor of a new one)
      
      Differential Revision: https://phab.mercurial-scm.org/D11709
      bf11ff22a9af
  7. May 19, 2021
  8. Jan 14, 2021
  9. Apr 06, 2021
  10. Nov 23, 2020
  11. Sep 13, 2020
    • Yuya Nishihara's avatar
      largefiles: walk history in ascending order while downloading all lfiles · b0d45612c552
      Yuya Nishihara authored
      I don't think the order matters. Maybe it's purely because of the use of
      walkchangerevs(), which was originally designed for "hg log" command.
      
      Surprisingly, the number of objects fetched in test-largefiles.t has changed.
      According to the --verbose output, the order of the following fetches flipped
      and the latter got deduplicated.
      
        getting large3:eb7338044dc27f9bc59b8dd5a246b065ead7a9c4
        found eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 in store
        getting sub/large4:eb7338044dc27f9bc59b8dd5a246b065ead7a9c4
        found eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 in store
      b0d45612c552
  12. Oct 14, 2018
    • Pierre-Yves David's avatar
      debugobsolete: also issue the "new obsmarkers" messsage · 34a46d48d24e
      Pierre-Yves David authored
      We are going to improve the way this message is issued in the core codebase.
      This will make it appears for `hg debugobsolete` too. Since this seems like a
      good idea, we make the output change in a previous changesets to clarify the
      next changeset.
      34a46d48d24e
  13. Jul 02, 2019
    • sliquister's avatar
      commit: improve the files field of changelog for merges · 99ebde4fec99
      sliquister authored
      Currently, the files list of merge commits repeats all the deletions
      (either actual deletions, or files that got renamed) that happened
      between base and p2 of the merge. If p2 is the main branch, the list
      can easily be much bigger than the change being merged.
      
      This results in various problems worth improving:
      - changelog is bigger than necessary
      - `hg log directory` lists many unrelated merge commits, and `hg log
        -v -r commit` frequently fills multiple screens worth of files
      - it possibly slows down adjustlinkrev, by forcing it to read more
        manifests, and that function can certainly be a bottleneck
      - the server side of pulls can waste a lot of time simply opening the
        filelogs for pointless files (the constant factors for opening even
        a tiny filelog is apparently pretty bad)
      
      So stop listing such files as described in the code.  Impacted merge
      commits and their descendants get a different hash than they would
      have without this. This doesn't seem problematic, except for
      convert. The previous commit helped with that in the hg->hg case (but
      if you do svn->hg twice from scratch, hashes can still change).
      
      The rest of the description is numbers. I don't have much to report,
      because recreating the files list of existing repositories is not
      easy:
      - debugupgradeformat and bundle/unbundle don't recreate the list
      - export/import tends to choke quickly applying patches or on
        description that contain diffs,
      - merge commits from the convert extension don't have the right files
        list for reasons orthogonal to the current commit
      - replaying the merge with hg update/hg merge/hg revert --all/hg
        commit can end up failing in hg revert
      - I wasn't sure that using debugsetparents + debugrebuilddirstate
        would really build the right thing
      
      I measured commit time before and after this change, in a case with no
      files filtered out, several files filtered out (no difference) and 5k
      files filtered out (+1% time).
      
      Recreating the 100 more recent merges in a private repo, the
      concatenated uncompressed files lists goes from 1.12MB to
      0.52MB. Excluding 3 merges that are not representative, then the size
      goes from 570k to 15k.
      I converted part of mozilla-central, and observed file list shrinking
      quite a bit too, starting at the very first merge, 733641d9feaf, going
      from 550 files to 10 files (although they have relatively few merges,
      so they probably wouldn't care).
      
      Differential Revision: https://phab.mercurial-scm.org/D6613
      99ebde4fec99
  14. Jun 20, 2019
    • Kyle Lippincott's avatar
      filemerge: make last line of prompts <40 english chars (issue6158) · 4764e8436b2a
      Kyle Lippincott authored
      I've chosen <40 as the target so that other languages that may have a 2x blowup
      in character count can still have a chance to fit into an 80 column screen.
      
      Previously, we would show a prompt like:
      
      ```
      keep (l)ocal [dest], take (o)ther [source], or leave (u)nresolved for some/potentially/really/long/path?
      ```
      
      On at least some systems, if readline was in use then the last line of the
      prompt would be wrapped strangely if it couldn't fit entirely on one line. This
      strange wrapping may be just a carriage return without a line feed, overwriting
      the beginning of the line; example (100 columns wide, 65 character filename, and
      yes there's 10 spaces on the end, I assume this is to handle the user inputting
      longest word we provide as an option, "unresolved"):
      
      ```
      ng/dir/name/that/does/not/work/well/with/readline/file.txt? ave (u)nresolved for some/lon
      ```
      
      In some cases it may partially wrap onto the next line, but still be missing
      earlier parts in the line, such as below (60 columns wide, 65 character
      filename):
      
      ```
       rev], or leave (u)nresolved for some/long/dir/name/that/do
      s/not/work/well/with/readline/file.txt?
      ```
      
      With this fix, this looks like this on a 60 column screen:
      
      ```
      tool vim_with_markers (for pattern some/long/dir/name/that/d
      oes/not/work/well/with/readline/file.txt) can't handle binar
      y
      tool meld can't handle binary
      tool vim_with_markers can't handle binary
      tool internal:merge3 can't handle binary
      tool merge can't handle binary
      no tool found to merge some/long/dir/name/that/does/not/work
      /well/with/readline/file.txt
      file 'some/long/dir/name/that/does/not/work/well/with/readli
      ne/file.txt' needs to be resolved.
      You can keep (l)ocal [working copy], take (o)ther [merge rev
      ], or leave (u)nresolved.
      What do you want to do?
      ```
      
      Differential Revision: https://phab.mercurial-scm.org/D6562
      4764e8436b2a
  15. Jan 09, 2019
    • Matt Harbison's avatar
      convert: don't drop commits that are empty in the source when using --filemap · 69804c040a04
      Matt Harbison authored
      I ran into this when using `hg lfconvert --to-normal` (which uses the filemap
      class internally), and saw that commits with nothing but a branch change were
      dropped.  We could put in an option that only lfconvert uses internally.  But
      silently dropping anything other than a commit where all changes were excluded
      seems unintended.  For example, there's a message in mercurial_sink.putcommit()
      if it drops an empty commit.  (And the reason that isn't kicking in here is
      because lfconvert isn't passing --filemap, so the self.filemapmode conditional
      there is always False.)
      
      The naive change of `return not files` broke test-convert-filemap.t, so this is
      a little more elaborate than needed for converting from largefiles.
      69804c040a04
  16. Nov 12, 2018
  17. Nov 01, 2018
  18. Sep 04, 2018
  19. Aug 16, 2018
  20. Apr 05, 2018
  21. Apr 03, 2018
  22. Apr 04, 2018
  23. Jan 08, 2018
    • Pulkit Goyal's avatar
      merge: add `--abort` flag which can abort the merge · 41ef02ba329b
      Pulkit Goyal authored
      Currently we don't have a good functionality to abort the merge and tell user to
      do `hg update -C .` which can leads to different results if user missed the '.'
      and moreover does not align with other abort functionalities like rebase, shelve
      etc.
      
      This patch adds `hg merge --abort` which will abort the ongoing merge and take
      us back to the chagneset where we started from. Works in both cases when merge
      resulted in conflicts and when there were no conflicts.
      
      .. feature::
      
          A `--abort` flag to merge command to abort the ongoing merge.
      
      Differential Revision: https://phab.mercurial-scm.org/D1829
      41ef02ba329b
  24. Dec 11, 2017
    • Matt Harbison's avatar
      tests: remove (glob) annotations that were only for '\' matches · 4441705b7111
      Matt Harbison authored
      # skip-blame because this was mechanically rewritten the following script.  I
      ran it on both *.t and *.py, but none of the *.py changes were proper.  All *.t
      ones appear to be, and they run without addition failures on both Windows and
      Linux.
      
        import argparse
        import os
        import re
      
        ap = argparse.ArgumentParser()
        ap.add_argument('path', nargs='+')
        opts = ap.parse_args()
      
        globre = re.compile(r'^(.*) \(glob\)(.*)$')
      
        for p in opts.path:
            tmp = p + '.tmp'
            with open(p, 'rb') as src, open(tmp, 'wb') as dst:
                for line in src:
                    m = globre.match(line)
                    if not m or '$LOCALIP' in line or '*' in line:
                        dst.write(line)
                        continue
                    if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'):
                        dst.write(line)
                        continue
                    dst.write(m.group(1) + m.group(2) + '\n')
            os.unlink(p)
            os.rename(tmp, p)
      4441705b7111
  25. Nov 29, 2017
    • Matt Harbison's avatar
      convert: avoid wrong lfconvert defaults by moving configitems to core · 281214150561
      Matt Harbison authored
      The `hg lfconvert --to-normal` command uses the convert extension internally to
      work its magic, but that produced devel-warn messages if the convert extension
      wasn't loaded by the user.  The test in fcd2f9b06629 (modified here) wasn't
      showing the warnings because the convert extension was loaded via $HGRCPATH.
      Most of the config options default to None/False, but 'hg.usebranchnames' and
      'hg.tagsbranch' are supposed to default to True and 'default' respectively.
      
      The first iteration of this was to ui.setconfig() inside lfconvert, to force the
      convert extension to load.  But there really is no precedent for doing this, and
      check-config complained that 'extensions.convert' isn't documented.  Yuya
      suggested this alternative.
      
      This partially backs out 0d5a1175d0f9.
      281214150561
  26. Sep 28, 2017
    • Boris Feld's avatar
      config: use 'experimental.evolution.create-markers' · 1644623ab096
      Boris Feld authored
      Extract 'experimental.evolution' = createmarkers as
      'experimental.evolution.createmarkers'.
      
      We keep the new option in the 'experimental.evolution' namespace in order to
      stay coherent with other options ('experimental.evolution.bundle-obsmarker'
      and 'experimental.evolution.track-operation') ease the renaming as possibly
      'evolution.createmarkers'.
      
      Differential Revision: https://phab.mercurial-scm.org/D1149
      1644623ab096
  27. Sep 16, 2017
  28. Aug 14, 2017
  29. Aug 04, 2017
  30. Jul 16, 2017
  31. Oct 16, 2015
  32. Oct 12, 2015
  33. Oct 09, 2015
    • Siddharth Agarwal's avatar
      simplemerge: move conflict warning message to filemerge · ef1eb6df7071
      Siddharth Agarwal authored
      The current output for a failed merge with conflict markers looks something like:
      
        merging foo
        warning: conflicts during merge.
        merging foo incomplete! (edit conflicts, then use 'hg resolve --mark')
        merging bar
        warning: conflicts during merge.
        merging bar incomplete! (edit conflicts, then use 'hg resolve --mark')
      
      We're going to change the way merges are done to perform all premerges before
      all merges, so that the output above would look like:
      
        merging foo
        merging bar
        warning: conflicts during merge.
        merging foo incomplete! (edit conflicts, then use 'hg resolve --mark')
        warning: conflicts during merge.
        merging bar incomplete! (edit conflicts, then use 'hg resolve --mark')
      
      The 'warning: conflicts during merge' line has no context, so is pretty
      confusing.
      
      This patch will change the future output to:
      
        merging foo
        merging bar
        warning: conflicts while merging foo! (edit, then use 'hg resolve --mark')
        warning: conflicts while merging bar! (edit, then use 'hg resolve --mark')
      
      The hint on how to resolve the conflicts makes this a bit unwieldy, but solving
      that is tricky because we already hint that people run 'hg resolve' to retry
      unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker
      based resolution.
      ef1eb6df7071
  34. Jun 07, 2015
  35. Jun 08, 2015
  36. May 28, 2015
    • Matt Harbison's avatar
      largefiles: use the convert extension for 'lfconvert --to-normal' · fcd2f9b06629
      Matt Harbison authored
      The logic in the convert extension is more advanced, supporting extra features
      like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
      updating hashes in commit messages, and outputs an SHA map file.  Rather than
      try to duplicate all of that, just use the existing code.
      
      Even though the convert extension supports user supplied options like filemap,
      etc, those features aren't available on the lfconvert interface.  Therefore, it
      is safe to use the filemap mechanism (in memory) to handle the standin -> file
      rename.  The convert extension handles the destination locking for this path.
      
      There was a comment in test-lfconvert.t about the hash on rev 5 being different
      because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
      It isn't clear to me what was happening or why, but now the hashes match the
      original repo exactly after a roundtrip, which seems like a good idea.  If there
      really was something beneficial about the previous behavior, perhaps merge can
      be changed so that everyone benefits.
      
      Converting to a largefiles repo still uses the original (limited) lfconvert
      logic.
      fcd2f9b06629
  37. Aug 19, 2014
  38. Jul 26, 2014
Loading