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

[Shawn Singh]

Awesome.... thanks very much. =)

Yeah, the way you proposed to deal with it seems better, now I think of it.

~Shawn

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.
>
> ~Shawn
>
>
>
> 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>
>> wrote:
>> > 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.
>> >
>>
>> 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
>> Changelog.
>>
>> -- Dirk
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120229/b2c03ad3/attachment-0001.html>