Re: [PATCH 0/6] easy bulk commit creation in tests

[Elijah Newren <newren@gmail.com>]

On Fri, Jun 28, 2019 at 6:32 PM Jeff King <peff@peff.net> wrote:
>
> On Fri, Jun 28, 2019 at 02:53:26PM +0200, Johannes Schindelin wrote:
>
> > > > It would be nice if we had a "test_commits_bulk" that used fast-import
> > > > to create larger numbers of commits.
> > >
> > > So here's a patch to do that.
> >
> > I like the direction, especially because it would make it super easy to go
> > one step further that would probably make a huge difference on Windows: to
> > move `test_commit_bulk` to `test-tool commit-bulk`.
>
> I actually considered going directly there, but I don't think it would
> make a big difference. In the biggest case we dropped 900 processes to
> 4. If we really want to drop that to 1, we can:
>
>   - use a temp-file to avoid the left-hand-pipe subshell
>
>   - add a feature to fast-import to say "build on top of ref X", instead
>     of using to use rev-parse to manually generates a "reset" line
>     (maybe this is even possible already; I searched for it, but not
>     very hard).

It already exists; quoting the fast-import documentation:

"The special case of restarting an incremental import from the
current branch value should be written as:

            from refs/heads/branch^0

The ^0 suffix is necessary as fast-import does not permit a branch
to start from itself, and the branch is created in memory before
the from command is even read from the input. Adding ^0 will force
fast-import to resolve the commit through Git's revision parsing
library, rather than its internal branch table, thereby loading in
the existing value of the branch."

>   - add a feature to fast-import to have it check out the result of HEAD
>     if it was updated

That'd be cool if you could work out the various special cases; it'd
be nice to avoid the 'git reset --hard HEAD' afterwards that I always
do.

> The third one is a little less elegant to me, because there are a lot of
> questions about how to checkout (e.g., with "-f", what happens to
> deleted files, etc).

There's a question with deleted files?  Why wouldn't you just delete
them from the index and working tree?  The more interesting questions
to me in this case is what to do if the index or working tree were
dirty before the import started; that seems like a mess, though maybe
it's just a case where you abort before even importing.  On a similar
note, though, there could have been an untracked file that is in the
way of a now-to-be-tracked file that you might not want to lose.

Elijah