Re: Patch (apply) vs. Pull

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Jun 23, 2005, 08:36 UTC
Message-ID: <46a038f905062301363c3c1ea8@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.58.0506211452110.2353@ppc970.osdl.org>

On 6/22/05, Linus Torvalds <torvalds@osdl.org> wrote:

> Btw, I'd like to help automate the 6-7 stage with a different kind of
> merge logic.

(...)

Show 29 quoted lines

>  - get the different HEAD info set up, and save the original head in
>    ORIG_HEAD, the way "git resolve" does for real merges:
> 
>         : ${GIT_DIR=.git}
> 
>         orig=$(git-rev-parse HEAD)
>         new=$(git-rev-parse FETCH_HEAD)
>         common=$(git-merge-base $orig $new)
> 
>         echo $orig > $GIT_DIR/ORIG_HEAD
> 
>  - fast-forward to the new HEAD. We'll want to re-base everything off
>    that. If that fails, exit out - we've got dirty state
> 
>         git-read-tree -m -u $orig $new && exit 1
> 
>  - for each commit that we had in our old tree but not in the common part,
>    try to re-base it:
> 
>         > FAILED_TO_CHERRYPICK
>         for i in $(git-rev-list $orig ^$common)
>         do
>                 git-cherry-pick $i ||
>                         (echo $i >> FAILED_TO_CHERRYPICK)
>         done
>         if [ -s FAILED_TO_CHERRYPICK ]; then
>                 echo Some commits could not be cherry-picked, check by hand:
>                 cat FAILED_TO_CHERRYPICK
>         fi

Re-base and replay local history is an approach I've been using successfully with Arch (though it takes literally ages). Ideally, the process should be able to be restarted after one call to git-cherry-pick fails. It is usually a handful of patches in a series of a few hundred that will break, usually because it's been fed upstream. You want to resolve the conflict and resume somehow.

Show 8 quoted lines

> and here the "git-cherry-pick" thing is just a script that basically takes
> an old commit ID, and tries to re-apply it as a patch (with author data
> and commit messages, of course) on top of the current head. It would
> basically be nothing more than a "git-diff-tree $1" followed by tryign to
> figure out whether it had already been applied or whether it can be
> applied now.
> 
> What do you think?

Sounds great.

It might be useful to provide it a "skip" list, so that it skips applying selected patches (that have presumably made it upstream).

And perhaps --stop-at <commit-sha> so that if a large replay fails or yields a broken tree (not at the git level, but at the /does it compile and run/ level), I can throw away the temporary repo where I'm working and try again in shorter batches, stopping at "strategical" points.

cheers,

martin