Re: Odd problems trying to build an orphaned branch

[Jeff King <peff@peff.net>]

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

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

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