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 <cjerdo...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
