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 <shawnsi...@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 <dpra...@chromium.org> wrote: > >> On Wed, Feb 29, 2012 at 3:06 PM, Shawn Singh <shawnsi...@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 >> > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
