[webkit-dev] spinoff from webkit-patch -g discussion

[Shawn Singh]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120229/c3b5a7d7/attachment.html>