Re: rebasing topic/libposix

[Gary V. Vaughan]

Howdy Bruce,

On 5 May 2011, at 03:22, Bruce Korb <address@hidden> wrote:
> Not being a GIT guru, I had previously done "git merge" to
> synchronize topic/libposix with master.  Seemed straight
> forward and obvious to me.  However, "rebase" is a better
> spelling for the proper process of resynchronization.

I'm also very far from being a git guru - but I'm pretty sure that rebasing
a public branch is a bad idea, especially for any poor souls who have a
working copy in the existing libposix branch.

> So,
> I did a "git rebase" and it was a mess.  Lots of stuff would
> not apply.  Consequently, I did a "git rebase --skip" over
> and over.  The net result being that some patches did not
> get applied -- they got skipped.  I detected the problems
> by comparing the final result with the current topic/libposix.
> Shocker: it was not the same.  So, where it wasn't the same,
> I copied back the current version of the files, yielding the
> patch below. (Note that the process actually yields 171 automated
> patches, plus the final manual clean-it-up patch.)
> 
> Question for folks that spend more time on gnulib and GIT than
> I do -- Should I:
> 
> 1. push this rebased thingey
> 2. go back and merge once again
> 3. start a topic/libposix-this-time-for-sure branch,
>   basically rolling up all the changes into a single patch.
>   (I cannot think that Gary and my collections of patches
>   is going to have a terrible lot of historical interest.
>   I could be wrong, but I do doubt it.)

If a merge from master to libposix proves problematic, then I would
create a local temporary merge branch  from HEAD of master, and
cherrypick each of the dozen or so libposix patches into that - from
there the local branch will merge easily enough to libposix, and can
be safely pushed without trying to change history.

If you'd like, I'll have time to make the merge on Saturday.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)