Re: Odd problems trying to build an orphaned branch

From: Jeff King <peff@peff.net>
Date: Nov 6, 2015, 19:00 UTC
Message-ID: <20151106190016.GA6830@sigill.intra.peff.net>
In-Reply-To: <929fa95cedaa2d2588753864b77380e9.squirrel@clueserver.org>

On Fri, Nov 06, 2015 at 10:32:56AM -0800, alan@clueserver.org wrote:

Show 8 quoted lines

> > Yes. There is no defined format for merge patches, so git-format-patch
> > cannot show them. What you're trying to do won't work.
> 
> This makes me worry about using git-format-patch. If it cannot handle
> merge commits correctly, then using it to send patches to customers is
> risky at best. (I work for a place that does not want to distribute the
> kernel, just patches on top of the kernel. The case of having a large
> number of merge commits in the tree seems to break that.)

If you do not know if the history contains merges and are blindly using format-patch, you are right to be worried. It will not work well for your case.

> > Was it a local clone? Depth is ignored for those (it _should_ print a
> > warning). If so, try --no-local to make it act like a "regular" clone.
> 
> I did not add any options for "local" vs "regular". What defines that?

If the clone is on the local filesystem (i.e., the source is a regular path, not a URL or an ssh endpoint), git will optimize some of the transfer. For example, it will hardlink objects, which makes computing a shallow clone more expensive than simply providing all of the objects.

But it should warn in this case.

For example:

  $ git clone --depth=1 /home/peff/compile/linux clone-of-linux
  Cloning into 'clone-of-linux'...
  warning: --depth is ignored in local clones; use file:// instead.
  done.

You can disable these local optimizations by using a "file://" URL instead of just a filename, or by using the "--no-local" flag.

Show 6 quoted lines

> > Of course that leaves only the problem that filter-branch is
> > horrendously slow (for the kernel, most of the time goes to populating
> > the index for each commit; I think filter-branch could probably learn to
> > skip this step if there is no index or tree filter at work).
> 
> I have to only run this once, so I don't care. Running at all would be nice.

It may be sufficiently slow on the kernel that it will not count as "running it all". :)

The patch I posted earlier seemed to make it workable.

Yet another option (because you wanted more, right?) is to pipe git-fast-export into git-fast-import. Something like:

  git fast-export \
    --no-data \
    --refspec refs/heads/master:refs/heads/filtered \
    v3.12-rc1..master |
  git fast-import

I don't know if there are any gotchas there, though.

-Peff