Skip to content
Snippets Groups Projects
  1. Nov 24, 2017
  2. Nov 20, 2017
  3. May 15, 2015
    • Sean Farley's avatar
      fetch: mark remote HEAD as public phase · a70c1f6c
      Sean Farley authored
      To help improve the speed Mercurial operations, we shouldn't leave the whole
      repository in the draft phase. The only hueristic git has for 'public' is
      remote HEAD. Therefore, if remote HEAD exists then we use it to mark the
      corresponding local commit as public.
      
      For now, we'll put this behind a config flag for easier rollback.
      a70c1f6c
  4. Nov 02, 2017
  5. Oct 24, 2017
  6. Oct 23, 2017
  7. Aug 17, 2017
  8. Aug 04, 2017
    • Katsunori FUJIWARA's avatar
      gitdirstate: show pattern error in hgignore file as expected · cf982a23
      Katsunori FUJIWARA authored
      Before this revision, invalid pattern in hgignore file causes
      unintentional failure for UnboundLocalError of ignorefunc, if hggit is
      used with Mercurial 3.5 or later.
      
      In such case:
      
        - checking source of invalid pattern at failure uses "pats" list for
          hgignore files, but
      
        - "pats" list is empty, if ignoremod is None (= Mercurial 3.5 or later)
      
        - therefore, checking with matchmod.match() overlooks invalid pattern
      
      Then, "return ignorefunc" is executed without assignment to
      ignorefunc, and causes UnboundLocalError.
      
      To show pattern error in hgignore file as expected even with Mercurial
      3.5 or later, this revision puts '(FILE, ["include: FILE"])' tuples
      into "pats" (to avoid code duplication, putting into allpats is
      shared, too).
      
      This makes checking source of invalid pattern at failure work as
      expected for hgignore files.
      
      Fixes #197
      cf982a23
  9. Aug 10, 2017
  10. Aug 04, 2017
  11. Jul 24, 2017
  12. May 22, 2017
  13. Dec 18, 2016
    • Gregory Szorc's avatar
      tests: add tests for git.findcopiesharder · dd5afdfe
      Gregory Szorc authored
      Previously, no explicit tests existed for this feature.
      
      The added tests demonstrate that git.findcopiesharder results in
      copy metadata being added to changesets adding files that were
      unmodified by that changeset.
      dd5afdfe
  14. Jan 08, 2016
  15. Oct 06, 2016
    • Sietse Brouwer's avatar
      revset_gitnode: allow abbreviated hashes · a128b9a5
      Sietse Brouwer authored
      The previous implementation only allowed passing 40-hexdigit hashes or
      12-hexdigit abbreviations to `gitnode(hash)`. Shorter or longer hashes
      were accepted, but failed silently. With this fix, any unambiguous
      abbreviation is accepted. `gitnode(a5b)` selects the revision whose Git hash
      starts with `a5b`, if there is one, and aborts if there are several.
      a128b9a5
  16. Sep 12, 2016
  17. Sep 03, 2016
    • Sean Farley's avatar
      gitdirstate: only wrap for hg-git repos · 9c15c890
      Sean Farley authored
      Previously, if a user enables hg-git and in a non-git repo (i.e.
      hg-only) they have a .gitignore, then hg-git will try to parse that. I
      consider this a bug and a bad performance regression for what should be
      a no-op.
      9c15c890
  18. Apr 20, 2016
  19. Feb 04, 2016
  20. Feb 02, 2016
  21. Jan 14, 2016
  22. Dec 31, 2015
  23. Oct 16, 2015
  24. May 17, 2015
    • Sean Farley's avatar
      refs: use dulwich to read remote refs · 1a1d90e3
      Sean Farley authored
      It is unclear to me why we keep a file (which can become out of sync) of remote
      refs instead of just using dulwich. This caught a missing remote ref in the
      test suite.
      1a1d90e3
  25. Jul 17, 2015
    • Sean Farley's avatar
      init: fix default hg breakage by returning the right type · 7c80e9f8
      Sean Farley authored
      Originally, I copied the logic for the file scheme which calls
      _peerlookup(path) but in mercurial/hg.py they have:
      
          try:
              return thing(path)
          except TypeError:
              return thing
      
      So, our http(s) scheme broke default Mercurial because I tried returning
      thing(path) instead of just thing. A test has been added to catch this.
      7c80e9f8
  26. Jun 14, 2015
    • Sean Farley's avatar
      import_git_commit: skip hgsubstate logic if file was deleted · 3246f2fa
      Sean Farley authored
      Previously, there was an edge case for Git repositories that started as
      Mercurial repositories and had used subrepos where a deleted .hgsubstate would
      be ignored and therefore reintroduced.
      
      This patch fixes that behavior by checking for the deleted .hgsubstate file
      first.
      
      A test has been added to verify behavior.
      3246f2fa
  27. Jun 11, 2015
    • Durham Goode's avatar
      gitimport: add save frequency config · 6aa31a3b
      Durham Goode authored
      If the importer encountered an error half way through a large import, all the
      commits are saved, but the mapfile is not written, so the process starts over
      from the beginning when run again.
      
      This adds the option for a config value that will save the map file every X
      commits. I thought about just hard coding this to 100 or something, but doing it
      this way seems a little less invasive.
      6aa31a3b
  28. Jun 01, 2015
  29. May 28, 2015
  30. May 12, 2015
  31. May 03, 2015
  32. Mar 12, 2015
  33. Feb 27, 2015
    • Siddharth Agarwal's avatar
      git_handler: don't store rename source if branch info is stored · a3b12aa1
      Siddharth Agarwal authored
      Consider a Mercurial commit with hash 'h1'. Originally, if the only Mercurial
      field stored is the branch info (which is stored in the commit message rather
      than as an extra field), we'd store the rename source explicitly as a Git extra
      field -- let's call the original exported hash 'g1'.
      
      In Git, some operations throw all extra fields away. (One such example is a
      rebase.) If such an operation happens, we'll be left with a frankencommit with
      the branch info but without the rename source. Let's call this hash 'g2'. For a
      setup where Git is the source of truth, let's say that this 'g2' frankencommit
      is what gets pushed to the server.
      
      When 'g2' is subsequently imported into Mercurial, we'd look at the fact that
      it contains a Mercurial field in the commit message and believe that it was a
      legacy commit from the olden days when all info was stored in the commit
      message. In that case, in an attempt to preserve the hash, we wouldn't store
      any extra rename source info, resulting in 'h1'. Then, when the commit is
      re-exported to Git, we'd add the rename source again and produce 'g1' -- and
      thus break bidirectionality.
      
      Prevent this situation by not storing the rename source if we're adding branch
      info to the commit message. Then for 'h1' we export as 'g2' directly and never
      produce 'g1'.
      
      What happens if we not only need to store branch info but also other extra
      info, like renames? For 'h1' we'd produce 'g1', then it'd be rewritten on the
      Git side to 'g2' throwing away all that extra information. 'g2' being
      subsequently imported into Mercurial would produce a new hash, say 'h2'. That's
      fine because the commit did get rewritten in Git. We unfortunately wouldn't
      perform rename detection thinking that the commit is from Mercurial and had no
      renames recorded there, but when the commit is re-exported to Git we'd export
      it to 'g2' again. This at least preserves bidirectionality.
      a3b12aa1
Loading