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

[Ojan Vafai]

tonikitoo, aroben, ddkilzner: You are the three who I remember voicing
yourselves about wanting webkit-patch to support committing/uploading
multiple patches from the same branch. Would Chris's suggestion below (last
couple paragraphs) be acceptable to you? I prefer it as it makes
webkit-patch less confusing to people who aren't very comfortable with git,
but it does not 100% meet the needs you've asked for in the past.

On Thu, May 13, 2010 at 1:30 PM, Chris Jerdonek <cjerdonek at webkit.org>wrote:

> Maybe it already does this, but would it be possible to make the default
> behavior be to throw an error if there is more than one possibility for
> what should be committed?


That's what it currently does.


> It seems like this would reduce the chance of
> accidentally committing the wrong information.  A configuration option
> could still be used to override this behavior for those who know they want
> to use one of the two behaviors exclusively.
>

I think the --squash behavior is actually pretty simple. It's a lot like
svn. It commits everything in your branch. End of story. Now that
https://bugs.webkit.org/show_bug.cgi?id=38852 is almost fixed, it's much
safer as well.


> I also suggest this because it's not clear to me that there are only two
> camps.  For example, I maintain one branch per bug (branch-per-bug), but I
> will often create a branch from one of these when working on a bug that
> depends on another of my bugs being landed (commit-per-bug).  So I can see
> myself using both options.
>

I don't actually see what the third option here is. I'd call both of those
approaches branch-per-bug. You'll commit the first branch using --squash and
then you can commit the second branch with --squash. That said, I find
myself using --squash ~80% of the time and --git-commit the other 20%.
Changing the default or the webkit-patch.squash value does not preclude you
using another value via the command-line (i.e. command-line overrides both).


> Finally, I'm wondering if the three options above could perhaps be
> simplified
> to a single option if we made it clear that webkit-patch supports working
> with only one revision at a time.


I agree, but you're essentially saying everyone should use branch-per-bug.
There are enough people who specifically use git for the commit-per-bug
approach that I don't think webkit-patch will meet everyone's needs if we do
this.


>  It doesn't seem like the semantics of
> webkit-patch extend clearly to multiple revisions.  For example, would
> the --reviewer flag need to be a delimited list to support one reviewer
> per revision, and would --test cause the tests to be run before all
> revisions, or before each revision?
>

I think most of the semantics can, in theory, be made to work fine with
multiple revisions and the ones that can't, like these two, should error if
used with a multi-revision command. That said, I don't intend to make these
changes. I'm hoping someone from the commit-per-bug camp will step up to do
it.


> If webkit-patch supported only one revision at a time, then it seems like
> the three options could be reduced to a single --git-commit option, which
> would specify which commits should go into creating the single
> revision/patch.
> From this perspective, the --squash option seems equivalent to specifying
> "all local changes" for the --git-commit option.  If we were to do this,
> maybe the --squash option could be replaced by a special value for the
> --git-commit option (for example --git-commit=*), and there could still
> be a configuration value to specify that --git-commit should always be "*".
>

I would be very happy with this. It would greatly simplify webkit-patch
(both the code and usage). However, we're basically saying we won't
explicitly support commit-per-bug workflows. If someone wanted to
upload/commit a range of commits as separate patches, they need to do each
one as a separate command. That said, people who want to do commit-per-bug
workflow could easily write a script that calls webkit-patch in a loop for
each commit.

There's a couple edge cases that are unclear to me. a) How do you upload
just the working copy? Is that the default? b) Does --git-commit=* include
the working copy? I think it should.

If we can get something resembling consensus, I'm happy to push the code in
this direction. If there's noone actually willing to make the commit-per-bug
workflow work, then perhaps we should move in this direction anyways instead
of leaving something half-finished in webkit-patch. Someone can always come
later and make the commit-per-bug workflow work.

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100514/78ff7897/attachment.html>