[webkit-dev] spinoff from webkit-patch -g discussion
shawnsingh at chromium.org
Wed Feb 29 16:41:46 PST 2012
Awesome.... thanks very much. =)
Yeah, the way you proposed to deal with it seems better, now I think of it.
On Wed, Feb 29, 2012 at 4:33 PM, Shawn Singh <shawnsingh at google.com> wrote:
> Awesome.... thanks very much. =)
> Yeah, the way you proposed to deal with it seems better, now I think of it.
> On Wed, Feb 29, 2012 at 3:28 PM, Dirk Pranke <dpranke at chromium.org> wrote:
>> On Wed, Feb 29, 2012 at 3:06 PM, Shawn Singh <shawnsingh at chromium.org>
>> > 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
>> >> bz.
>> >> You can do this with the current -g option by adding a commit range,
>> >> -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
>> >> 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,
>> > 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
>> > 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.
>> No, you are not missing something; this is actually one of the main
>> reasons I started the thread.
>> > 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.
>> In my view, I would actually rather upload the combination of
>> committed + staged + unstaged changes rather than be told I have to
>> commit things; in other words, I actually prefer to commit what I've
>> uploaded rather than upload what I've committed.
>> landing directly shouldn't be an an issue, insofar as webkit-patch
>> will stop (or at least warn) you if you still have an OOPS in the
>> -- Dirk
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev