From: Jeff King <peff@peff.net>
Date: Tue, 13 Sep 2011 03:29:00 GMT
Subject: Re: Okay to invoke merge-recursive with an empty workdir?
Message-ID: <20110913032900.GA3296@sigill.intra.peff.net>
In-Reply-To: <CAG+J_Dyz-aeLYn43ARTG4GJz0+zRw_RyDr80bmPCayd9BjzCwg@mail.gmail.com>

On Mon, Sep 12, 2011 at 11:13:37PM -0400, Jay Soffian wrote:

> So my approach is to create a temporary, empty, workdir, using
> symlinks to point to the parent repo per git new-workdir.
> 
> I then invoke merge-recursive directly inside the temporary workdir.
> 
> The question is whether this is safe to do, or whether merge-recursive
> expects a fully populated working tree that matches the index. My easy
> test cases seem to work correctly, but I'm concerned that I sometimes
> get:

I'm not sure if we were ever using merge-recursive like that. Especially
with Elijah's latest patches to handle worktree dirtiness better, I
wouldn't be surprised if it has issues.

What we do now at GitHub is something like:

  export GIT_WORK_TREE=/some/tmpdir
  export GIT_INDEX_FILE=/some/tmpfile
  git read-tree -i -m --aggressive $merge_base $us $them
  git merge-index git-merge-one-file -a

I also have a patch to do the content-level merge in read-tree without
touching the filesystem at all. But we're not using it yet, and I should
probably write more tests for it. You can see it at:

  git://github.com/peff/git.git jk/read-tree-content-merge

It should produce the same results as the snippet above, but faster.
Both of those will obviously not handle renames or do recursive merges
like merge-recursive, of course.

-Peff