On Fri, Nov 06, 2015 at 10:32:56AM -0800, alan@xxxxxxxxxxxxxx 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html