[webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit
ojan at chromium.org
Fri Jul 9 16:06:21 PDT 2010
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.
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.
> 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
>>> > 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
>>> 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
>> Sound good?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev