Skip to content
Snippets Groups Projects
  1. May 03, 2015
  2. Apr 29, 2015
  3. Apr 22, 2015
  4. Apr 17, 2015
  5. Apr 16, 2015
  6. Apr 15, 2015
  7. Apr 10, 2015
    • Siddharth Agarwal's avatar
      git_mapfile.save_map: stop sorting the keys entirely · b56d4f4f
      Siddharth Agarwal authored
      There really is no point to this -- the sorting is expensive to compute and
      the structure is never actually used.
      
      For a mapfile with 1.5 million entries, this speeds up save_map from 3.6
      seconds to 0.87.
      
      This is probably the limit of the speedups we can get with pure-Python code.
      Any further speedups will have to be made by rewriting these bits in C.
      b56d4f4f
  8. Apr 13, 2015
  9. Apr 10, 2015
  10. Apr 03, 2015
  11. Mar 12, 2015
  12. Mar 06, 2015
  13. Mar 05, 2015
  14. 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
  15. Feb 23, 2015
  16. Feb 21, 2015
  17. 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
  18. Jan 30, 2015
Loading