Quote from the discussion:
> that's why I said that having something like webkit-patch upload > range_of_commits will be nice to have, as you wouldn't have to create a > new branch and rebase several commits, just to upload a new patch to the > bz. > > You can do this with the current -g option by adding a commit range, e.g. -g=commit1..commit2. AFAIK, the only thing you can't do currently with -g is pass a commit range *and* include the staged/working copy changes. > Under the hood it basically does what you described (create a new branch, copy the commits over as a single commit, upload from the branch, etc). I didn't want to hikack the other thread, but I wanted to discuss this -git-commit flag. It makes sense that we can't commit a commit range + unstaged changes, and its easy enough to commit before uploading. However, one problem I've encountered is that webkit-patch may make changes to the changelogs, in particular the "reviewed by" clause. But then, because its an unstaged change, it uploads the "reviewed by nobody" clause. So I have to manually edit the "reviewed by..." statement, commit, and then upload. Am I missing something simple? It seems to defeat the purpose of automatically editing the changelogs, if I still have to quit and commit it myself before uploading again. Would it be reasonable to force an error to upload a commit range, when there are unstaged changes? I've observed this only for land-safely and upload. I've been unwilling to experiment with landing directly because I don't want it to accidentally commit a "reviewed by nobody" to the changelogs. Thanks, ~Shawn
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
