On Fri, May 14, 2010 at 9:20 PM, David Kilzer ddkil...@webkit.org wrote:
Personally, I don't see why both models (single patches and multiple
patches) couldn't be supported based on the arguments passed to
webkit-patch. git itself seems to be able to figure out if the user is
referring to a single commit or a series of commits (based on the context of
the command-line arguments and what the command does), so I don't see why we
have to introduce additional command-line switches for various behavior.
(See the git-send-email command as an example since it's designed to send
email for a single patch or a series of patches.)
In my opinion, webkit-patch should default to single commit behavior unless
the user specifies a range. That way, git neophytes and the majority of
existing users get the single-commit-to-a-single-bug behavior by default.
However, if a range of commits is given, then webkit-patch would be smart
enough to post the series of patches to a single bug.
Right now, if you pass a commit-range it squashes all the commits into a
single commit. I don't think it would be a big deal to change that behavior.
The harder part is that webkit-patch is entirely built around single
commits, both from API and code. For example, it assumes a single reviewer
and commit message for the whole command. Changing that would be a lot of
work.
These are certainly solvable problems, but it's not clear to me that it's
worth trying to shoe-horn this use-case into webkit-patch. The more I think
about this, the more I think we should use Chris's proposal (detailed below)
and write a separate script for dealing with commit-ranges in that way.
webkit-patch is much simpler if we keep it's semantics simple and writing a
script that calls webkit-patch in a loop and only exposes the sensible
options is relatively easy.
On Sat, May 15, 2010 at 2:17 PM, Chris Jerdonek cjerdo...@webkit.orgwrote:
It would support a commit-per-bug workflow. Just not committing a patch
series all at once with a single invocation of webkit-patch (at least
for now -- see below).
Yup. I think that's the key point here and having a separate script
alleviates the tedium of needing to manually call webkit-patch multiple
times.
Personally, I think webkit-patch and check-webkit-style should include
unstaged changes when using the .. syntax.
This make sense to me.
I also don't think it
would be important for the scripts to make a distinction between unstaged
and staged changes -- in part because svn-apply does not behave uniformly
in this regard.
I agree.
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.
I propose:
default (--git-commit=..): operate on uncommitted changes. errors out if
there are committed changes and --git-commit wasn't explicitly passed in
--git-commit=head.. operate on uncommitted changes + head as a single
commit
--git-commit=head~3 operate on just head~3
--git-commit=head~4..head~2 operate on head~4, head~3 and head~2 as a
single commit
--git-commit=* operate on all changes in your branch as a single commit
Then we get rid of --squash and --no-squash.
Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
