Re: Odd problems trying to build an orphaned branch

[alan@clueserver.org]

> On Thu, Nov 05, 2015 at 01:16:54PM -0800, alan@clueserver.org wrote:
>
>> I created an orphan branch from 3.12-rc1. I then used git format-patch
>> to
>> generate patches from 3.12-rc1 to HEAD. (Over 7000 patches.) I use git
>> am
>> to apply them to the orphan branch. At patch 237 it fails to apply. (It
>> appears the patch is from a block of code added with a merge commit, but
>> it is somewhere in the middle of the block.)
>>
>> Are merge commits supposed to screw up git-format-patch?
>
> 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 your goal is to have the history at HEAD truncated at 3.12-rc1, you
> are probably better off using a graft and having "filter-branch" rewrite
> the history based on that. That will preserve merges and the general
> shape of history.

I tried using that.  The documentation on how to do it correctly is vague.
It seemed to want to take the patches before the graft point, not after.
When filter-branch hit a commit with no author, it died. (It does not
allow a rewrite of a commit that does not have an author.)

>
>> I also tried using clone with depth and --single-branch set.  It ignored
>> the depth setting and gave me the whole branch all the way back to
>> 2.6.x.
>
> 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?

>> I tried using graft and filter-branch. None of the descriptions are very
>> clear. None of them worked either. Filter-branch died on a commit
>> somewhere in 2.6 land that had no author. (Which is outside of the
>> commits
>> I want to keep.)
>
> I suspect you need to graft more than just the commit at v3.12-rc1. For
> example, consider this history graph:
>
>   --A--B--C--D---G--H
>            \    /
>             E--F
>
> If we imagine that H is the current HEAD, and D is our tag (v3.12-rc1),
> then making a cut between D and C will not have any effect on the side
> branch that contains E and F. Commits A and B are still reachable
> through them.
>
> You can find the complete set of boundary commits like this:
>
>   git log --boundary --format='%m %H' v3.12-rc1..HEAD
>
> and then graft them all like this:
>
>   git log --boundary --format='%m %H' v3.12-rc1..HEAD |
>     grep ^- | cut -d' ' -f2 >.git/info/grafts
>
> Then you should be able to run "git filter-branch" to rewrite the
> history based on that.
>
> I think you can probably get the same effect by running:
>
>   git filter-branch v3.12-rc1..HEAD

I will try this and see what happens.

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

>> I tried creating an orphan branch and using cherry-pick
>> v3.12-rc1..linux-3.12.y. It blew up on the first merge commit it hit. I
>> tried adding in "-m 1" to try to get it to pick a parent, but then it
>> died
>> on the first commit because it was not a merge.
>
> That won't do what you want. Cherry-pick doesn't preserve merges. When
> you pick a merge and choose a mainline, it is effectively saying "treat
> that as the only interesting parent" and squashes the result down to a
> single non-merge commit.
>
> If you wanted to follow this path (starting at an orphan and moving the
> patches over), I think rebase's "--preserve-merges" would be your best
> bet. It used to have some corner cases, though, and I don't know if
> those were ever fixed. I'd say filter-branch is the most-supported way
> to do what you want.
>
>> All I want to do is take a branch from linux-stable and create a branch
>> that contains just the commits from where it was branched off of master
>> until it hits HEAD. That is it. All the scripts that I have seen that
>> claim to do just what I want break when it hits a merge or a bogus
>> author.
>> (How that got into linux-stable, I have no idea. The commit is 10 year
>> old!)
>
> As an aside, which commit caused the bogus-author problem? Filter-branch
> generally tries to preserve or fix problems rather than barfing, exactly
> because it is often used to rewrite-out crap. I wonder if there is
> something it could be doing better (though again, I think in your case
> you are hitting the commit only because of an incomplete cut with your
> grafts).

I will try and find it again. It is in the 2.6 tree from 2005.