[webkit-dev] spinoff from webkit-patch -g discussion
shawnsingh at chromium.org
Wed Feb 29 15:06:08 PST 2012
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
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev