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
