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 <o...@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 <o...@chromium.org> wrote: > >> On Sun, May 16, 2010 at 10:38 AM, Chris Jerdonek <cjerdo...@webkit.org>wrote: >> >>> On Sun, May 16, 2010 at 8:26 AM, Ojan Vafai <o...@chromium.org> wrote: >>> > On Sat, May 15, 2010 at 2:17 PM, Chris Jerdonek <cjerdo...@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 >> > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev