<span style>Awesome.... thanks very much. =)</span><div style><br></div><div style>Yeah, the way you proposed to deal with it seems better, now I think of it.</div><div style><br></div><div style><div><div>~Shawn</div></div>
</div><br><div class="gmail_quote">On Wed, Feb 29, 2012 at 4:33 PM, Shawn Singh <span dir="ltr"><<a href="mailto:shawnsingh@google.com">shawnsingh@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Awesome.... thanks very much. =)<div><br></div><div>Yeah, the way you proposed to deal with it seems better, now I think of it.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><div><div><span class="HOEnZb"><font color="#888888">~Shawn</font></span><div>
<div class="h5"><br><div><br></div><div><br><div class="gmail_quote">
On Wed, Feb 29, 2012 at 3:28 PM, Dirk Pranke <span dir="ltr"><<a href="mailto:dpranke@chromium.org" target="_blank">dpranke@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Wed, Feb 29, 2012 at 3:06 PM, Shawn Singh <<a href="mailto:shawnsingh@chromium.org" target="_blank">shawnsingh@chromium.org</a>> wrote:<br>
> Quote from the discussion:<br>
><br>
>><br>
>> that's why I said that having something like webkit-patch upload<br>
>> range_of_commits will be nice to have, as you wouldn't have to create a<br>
>> new branch and rebase several commits, just to upload a new patch to the<br>
>> bz.<br>
><br>
><br>
>> You can do this with the current -g option by adding a commit range, e.g.<br>
>> -g=commit1..commit2. AFAIK, the only thing you can't do currently with -g is<br>
>> pass a commit range *and* include the staged/working copy changes.<br>
>> Under the hood it basically does what you described (create a new branch,<br>
>> copy the commits over as a single commit, upload from the branch, etc).<br>
><br>
> I didn't want to hikack the other thread, but I wanted to discuss this<br>
> -git-commit flag.<br>
><br>
> It makes sense that we can't commit a commit range + unstaged changes, and<br>
> its easy enough to commit before uploading.  However, one problem I've<br>
> encountered is that webkit-patch may make changes to the changelogs, in<br>
> particular the "reviewed by" clause. But then, because its an unstaged<br>
> change, it uploads the "reviewed by nobody" clause.  So I have to manually<br>
> edit the "reviewed by..." statement, commit, and then upload.<br>
><br>
> Am I missing something simple?  It seems to defeat the purpose of<br>
> automatically editing the changelogs, if I still have to quit and commit it<br>
> myself before uploading again.<br>
><br>
<br>
</div>No, you are not missing something; this is actually one of the main<br>
reasons I started the thread.<br>
<div><br>
> Would it be reasonable to force an error to upload a commit range, when<br>
> there are unstaged changes?  I've observed this only for land-safely and<br>
> upload.  I've been unwilling to experiment with landing directly because I<br>
> don't want it to accidentally commit a "reviewed by nobody" to the<br>
> changelogs.<br>
><br>
<br>
</div>In my view, I would actually rather upload the combination of<br>
committed + staged + unstaged changes rather than be told I have to<br>
commit things; in other words, I actually prefer to commit what I've<br>
uploaded rather than upload what I've committed.<br>
<br>
landing directly shouldn't be an an issue, insofar as webkit-patch<br>
will stop (or at least warn) you if you still have an OOPS in the<br>
Changelog.<br>
<span><font color="#888888"><br>
-- Dirk<br>
</font></span></blockquote></div><br></div></div></div></div></div></div>
</blockquote></div><br>