On Thu, May 13, 2010 at 11:13 AM, Ojan Vafai <o...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev