[webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit

[Ojan Vafai]

I posted a patch to https://bugs.webkit.org/show_bug.cgi?id=39624. Which
prompted further discussion on #webkit. We came to a different conclusion.
The basic idea is that webkit-patch should work right without any flags for
some workflow. We can make it work right for the branch-per-bug workflow and
write a separate wrapper script to make the commit-per-bug workflow work.
Specifically the behavior would be the following:

   - Squashing should be the default behavior. In cases where squashing
   might do something unexpected (e.g. commit multiple local changes), we'll
   prompt the user to see if they want to continue. The prompt can be avoided
   by adding webkit-patch.squash to the git config. There won't be any --squash
   or --no-squash commands.
   - --git-commit will work as outlined below except that * will no longer
   mean squash.

Unless I hear objections, I'll change my patch for bug 39624 to implement
the above.

Ojan

On Mon, May 17, 2010 at 2:21 PM, Ojan Vafai <ojan at chromium.org> wrote:

> On Sun, May 16, 2010 at 10:38 AM, Chris Jerdonek <cjerdonek at webkit.org>wrote:
>
>> On Sun, May 16, 2010 at 8:26 AM, Ojan Vafai <ojan at chromium.org> wrote:
>> > On Sat, May 15, 2010 at 2:17 PM, Chris Jerdonek <cjerdonek at webkit.org>
>> > wrote:
>> >>  In particular, --git-commit=HEAD.. should be just the
>> >> uncommitted changes (staged and unstaged).
>> >
>> > This one I'm a bit iffy on. Should this include the commit at head? I
>> think
>> > it should.
>>
>> Currently, when using check-webkit-style for example, I need to pass
>> --git-commit=HEAD^.. to include the commit at head.  In other words,
>> it operates on ranges like the above exclusively with respect to the
>> endpoint.  This is similar to how git-diff behaves and is described
>> here:
>>
>> http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html
>>
>> Were you thinking about changing this behavior?
>
>
> Someone also pointed out off thread that including working copy changes
> doesn't match any existing git commands. I think we should try to stay as
> close to git semantics as possible.  So, I'm revising the proposal.
>
> It weirds me out the --git-commit=head~3..head~2 and --git-commit=head~2 do
> the same thing, but it turns out most git commands work that way.
>
> I propose:
> default: operate on working copy changes. Errors if there are no working
> copy changes or if there are committed changes. Gives a nice error message
> saying what to do.
> --git-commit=*  operate on all changes in your branch as a single commit,
> including working copy changes
> --git-commit=head~2  operate on head~2
> --git-commit=head~2..  operate on head~2, head~1 and head
> --git-commit=head~4..head~2  operate on head~3 and head~2 as a single
> commit
>
> Sound good?
>
> Ojan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100524/ac5ab128/attachment.html>