Skip to content
Snippets Groups Projects
  1. 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
  2. Feb 23, 2015
  3. Feb 21, 2015
  4. 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
  5. Jan 30, 2015
  6. Jan 27, 2015
  7. Dec 30, 2014
  8. Nov 24, 2014
    • durin42's avatar
      hg2git: audit path components during export (CVE-2014-9390) · 81c55f86
      durin42 authored
      A user recently got confused and managed to track and export a .git
      directory, which confuses git and causes it to emit very odd
      errors. For example, cloning one such repository (which has a symlink
      for .git) produces this output from git:
      
        Cloning into 'git'...
        done.
        error: Updating '.git' would lose untracked files in it
      
      and another (which has a .git directory checked in) produces this:
      
        Cloning into 'git'...
        done.
        error: Invalid path '.git/hooks/post-update'
      
      If it ended there, that'd be fine, but this led to a line of
      investigation that ended with CVE-2014-9390, so now git will block
      checking these revisions out, so we should try to prevent
      foot-shooting on our end. Since some servers (notably github) are
      blocking trees that contain these entries, default to refusing to
      export any path component that looks like it folds to .git. Since some
      histories probably contain this already, we offer an escape hatch via
      the config option git.blockdotgit that allows users to resume
      foot-shooting behavior.
      81c55f86
  9. Dec 29, 2014
  10. Dec 10, 2014
  11. Dec 05, 2014
  12. Dec 02, 2014
    • Siddharth Agarwal's avatar
      git_handler: mark source for rename info as Git or Mercurial · fffe8883
      Siddharth Agarwal authored
      See inline comments for why the additional metadata needs to be stored.
      
      This literally breaks all the hashes because of the additional metadata. The
      changing of hashes is unfortunate but necessary to preserve bidirectionality.
      
      While this could be broken up into multiple commits, there was no way to do
      that while preserving bidirectionality. Following the principle that every
      intermediate commit must result in a correct state, I decided to combine the
      commits.
      fffe8883
    • Siddharth Agarwal's avatar
      git_handler.get_files_changed: detect renames when asked to do so · da804eac
      Siddharth Agarwal authored
      We use Dulwich's rename detector to detect any renames over the specified
      similarity threshold.
      
      This isn't fully bidirectional yet -- when the commit is exported to Git
      the hashes will no longer be the same. That's why that isn't tested here. In
      upcoming patches we'll make sure it's bidirectional and will add the
      corresponding tests.
      da804eac
  13. Dec 06, 2014
  14. Dec 02, 2014
  15. Dec 05, 2014
  16. Dec 01, 2014
  17. Nov 30, 2014
    • Siddharth Agarwal's avatar
      git_handler.export_git_objects: avoid unnecessary list creation · 799c41a2
      Siddharth Agarwal authored
      These are used just once, so generators are fine for them.
      799c41a2
    • Siddharth Agarwal's avatar
      git_handler.export_git_objects: filter out octopus explosions earlier · 4b5a18d2
      Siddharth Agarwal authored
      hg-git translates octopus merges into a series of merges, called an octopus
      explosion. The intermediate octopus explosion commits are not recorded in
      the mapfile -- only the final commit is. This means that they show up in the
      export list and have to then be detected and filtered out.
      
      Don't initialize the incremental exporter with octopus explosion commits.
      Previously, if there were octopus merges early in the history, we'd initialize
      the incremental exporter with the first one's parent, then calculate the diff
      of that against the first commit we actually cared about exporting. That's slow
      and wasteful.
      
      For a particular real-world repo with one octopus merge 1/3 of the way in
      history, this is a 10x improvement for 'hg gexport' with one commit to export
      -- 60 seconds to 6.
      4b5a18d2
    • Siddharth Agarwal's avatar
      git_handler: iterate over contexts, not nodes · 5fa9649c
      Siddharth Agarwal authored
      This prepares for an upcoming patch.
      
      In theory, we could pass the context into export_hg_commit, but there's some
      encoding shenanigans going on there that I don't want to delve into.
      5fa9649c
  18. Nov 25, 2014
    • Durham Goode's avatar
      manifest: add matches() to overlay · 64fa5ea1
      Durham Goode authored
      0cc283f44655 in upstream Mercurial added a matches function to the manifest.
      This broke 'hg incoming -p' with hg-git. This patch adds a simple implementation
      that fixes the problem.
      
      This was caught by the tests, and now the tests pass.
      64fa5ea1
  19. Nov 05, 2014
Loading