Skip to content
Snippets Groups Projects
  1. Nov 24, 2017
  2. 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
  3. 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
  4. Mar 25, 2014
  5. Jul 01, 2013
Loading