Skip to content
Snippets Groups Projects
  1. Oct 24, 2017
  2. Oct 23, 2017
  3. Aug 17, 2017
  4. 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
  5. Aug 10, 2017
  6. Aug 04, 2017
  7. Jul 24, 2017
  8. May 22, 2017
  9. 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
  10. Jan 08, 2016
  11. 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
  12. Sep 12, 2016
  13. 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
  14. Apr 20, 2016
  15. Feb 04, 2016
  16. Feb 02, 2016
  17. Jan 14, 2016
  18. Dec 31, 2015
  19. Oct 16, 2015
  20. 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
  21. 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
  22. 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
  23. 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
  24. Jun 01, 2015
  25. May 28, 2015
  26. May 12, 2015
  27. May 03, 2015
  28. Mar 12, 2015
  29. 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
    • Siddharth Agarwal's avatar
      test-renames.t: add tests for renaming a file out and replacing it with a submodule · 3004fd28
      Siddharth Agarwal authored
      Unlike the file to symlink transition discussed in the previous case, this case
      works fine.
      3004fd28
    • Siddharth Agarwal's avatar
      git_handler: handle case where file is renamed and replaced by a symlink · 4d246150
      Siddharth Agarwal authored
      This edge case that rename detection introduces wasn't handled previously --
      the file would be renamed but the symlink wouldn't be added.
      4d246150
  30. Feb 21, 2015
  31. Feb 16, 2015
    • Mathias De Maré's avatar
      gitdirstate: avoid an abort when a .gitignore is missing · cdf46071
      Mathias De Maré authored
      Deleting a .gitignore using 'rm' results in 'hg add' or 'hg status' aborting.
      For example if the top-level .gitignore is removed:
        > abort: No such file or directory: .gitignore
      This change avoids that by checking the presence of the .gitignore files.
      cdf46071
Loading