1. 27
  1.  

  2. 3

    +Semi-related work

    +Replacements (refs/replace) are superficially similar to obsolescences in that they describe that one commit should be replaced by another.

    git replace is new to me. When did it appear? Is anyone using it?

    I’ve also been meaning to try git absorb which looks thoughtfully designed.

    1. 4

      If I remember correctly, git replace was useful to me in a case where an old CVS repository had been imported without history to git and then worked on for a long, long time. Much later, the old CVS history was preserved by using a decent cvs2git kind of utility, creating another git repository. Git replace would then allow me to stitch these two repositories together, effectively prepending history (something which would be impossible to do with a normal git parent commit ref, without completely cracking sha1)

      1. 3

        Absorb is really nice if you’re using a fixup-heavy workflow. Fast, too.

        1. 1

          Are you an actual user of git absorb? Or are you talking about the hg original? I’ve wondered how usable it is for git already.

          1. 1

            Yes I use git absorb. Haven’t run into any problems yet 🙂

        2. 2

          I’m hoping to eventually integrate git absorb into git revise, which is basically a faster in-memory version of git rebase for rebases that don’t change the final file contents, just reorder when changes happen (i.e. 90% of my use cases for git rebase)

          1. 3

            Since that’s in Python you could probably take advantage of the linelog implementation that’s underneath hg absorb to make the work easier. I recommend looking at the hg absorb code. Linelog makes it easy and slightly more robust than just moving patch hunks around.