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

[Ojan Vafai]

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/20100517/a240d8dd/attachment.html>