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

[Ojan Vafai]

This has landed. Squashing is now the default behavior. --git-commit/-g
operates on the commit(s) listed as a single commit. --git-commit=HEAD..
operates on the working copy.

Ojan

On Mon, May 24, 2010 at 5:10 PM, Ojan Vafai <ojan at chromium.org> wrote:

> 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/20100709/1f451b9c/attachment.html>