Re: [Sbcl-devel] Merging unicode-algorithms (Google Summer of Code update)

[Krzysztof D. <krz...@gm...>]

On 08/05/2014 10:11 AM, Christophe Rhodes wrote:
> Krzysztof Drewniak <krz...@gm...> writes:
> 
>> On 08/05/2014 09:28 AM, Christophe Rhodes wrote:
[snip]
>>> What would make reviewing it easier is if there was a candidate branch
>>> for merging -- maybe a temporary branch rebased to master?  We try to
>>> provide the illusion of linear history in our master branch, so
>>> something like that is needed eventually anyway.
>> So, should I just do "git rebase master" on my checkout of sbcl and push
>> the new master to Github?
> 
> Ultimately, what will have to happen before merging into master is that
> a set of commits which can be merged "fast-forward" will have to be
> generated.  That set should aim to have as the minimal property that
> each commit builds (i.e. try to avoid including in that set any commits
> that break the build; this is important for later bisection, including
> for completely unrelated bugs), and as far as possible those commits
> should also be logical single changes.
> 
> The extremes in terms of rebasing to get to this point are:
> 
> - just rebase unicode-algorithms to master.  This does generate a set of
>   fast-forwardable commits, but probably fails the every-commit-builds
>   property (e.g. I see
>   <https://github.com/krzysz00/sbcl/commit/5232c20071254b61d32a82314a39f00c194f46e4>)
> 
> - rebase unicode-algorithms and squash everything into one big commit.
>   This generates a fast-forwardable commit, but fails the logical single
>   change test.
> 
> Finding a point in the middle is more of an art than a science; my
> initial suggestion would be to do check out a temporary branch from your
> unicode-algorithms branch, do the rebase, squash any commit that looks
> like a typo or build fixup (like the one above) into the commit that
> introduced that typo, probably the parent commit, and publish that
> branch?
> 
I've put together a very rough set of fast-forwardable commits that all
build at https://github.com/krzysz00/sbcl/tree/ua-integration . I had to
use `git merge --squash` and split off pieces because rebase was choking
on my reader changes no matter what I did (I basically rewrote that code
to be compatible with the new reader internals while resolving a merge
conflict).

The three earlier commits (that aren't IRC-suggested changes) are, roughly:

1) Big ball of interdependent new code that shouldn't break anything (I
*might* be able to split that up further, but extremely tediously)
2) Changes to #\
3) Changes to the reader for symbols.

I know this isn't really ideal as far as merging goes. Should I keep
poking at this problem, or is my current set of commits Good Enough (tm)?