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
