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

From: Elijah Newren <newren@gmail.com>
Date: Jun 29, 2019, 16:38 UTC
Message-ID: <CABPp-BEyq-9sj_9wxLdh66BJqqjQ80a8sCpXd_cMCArAHnM7kA@mail.gmail.com>
In-Reply-To: <20190629003057.GB3094@sigill.intra.peff.net>

On Fri, Jun 28, 2019 at 6:32 PM Jeff King <peff@peff.net> wrote:

Show 22 quoted lines

>
> 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