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

[Chris Jerdonek]

On Thu, May 13, 2010 at 11:13 AM, Ojan Vafai <ojan at chromium.org> wrote:
> I finally updated this
> page http://trac.webkit.org/wiki/UsingGitWithWebKit#webkit-patchcheck-webkit-styleandgit.
> As is clear from that, my earlier description of --no-squash was totally
> inaccurate. Sorry, I was being rushed. --no-squash and --git-commit still
> need significant work before they will work in the way the commit-per-bug
> camp wants it to. It's not too much work, but it's not trivial either.
> There are two clear camps with webkit-patch git usage. commit-per-bug and
> branch-per-bug. webkit-patch should support both. Which one is the default
> is a matter of preference. The current default is confusing and meets noones
> needs. I don't care which is the default as long as it's not the current
> middle-ground. I'd still like to make --squash the default since it is
> basically complete (except
> for https://bugs.webkit.org/show_bug.cgi?id=38852).
> There is little active work on --no-squash and --git-commit, so it's not
> clear how soon they'll be completed. So, unless the are objections, I'd like
> to do the following:
> 1. Fix https://bugs.webkit.org/show_bug.cgi?id=38852
> 2. Pick a date, e.g., June 1st, to make --squash the default. Send many
> ALL_CAPS emails warning people that the default behavior for webkit-patch
> and git checkouts is going to change.
> 3. Change it on June 1st.
> Which behavior is the default really doesn't matter since you can set
> webkit-patch.squash in your git config. I just want to get rid of the
> current default behavior and --no-squash isn't ready for that.


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?  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 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.

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.  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?

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 "*".

--Chris