Re: [openstack-dev] [all] Proper use of 'git review -R'

2015-01-05 Thread Carl Baldwin
On Tue, Dec 30, 2014 at 9:37 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-12-30 09:46:35 -0500 (-0500), David Kranz wrote: [...] Can some one explain when we should *not* use -R after doing 'git commit --amend'? [...] In the standard workflow this should never be necessary. The

Re: [openstack-dev] [all] Proper use of 'git review -R'

2015-01-05 Thread Carl Baldwin
On Tue, Dec 30, 2014 at 11:24 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-12-30 12:31:35 -0500 (-0500), David Kranz wrote: [...] 1. This is really a UI issue, and one that is experienced by many. What is desired is an option to look at different revisions of the patch that show only

Re: [openstack-dev] [all] Proper use of 'git review -R'

2015-01-05 Thread Adam Young
On 12/30/2014 11:47 AM, Jeremy Stanley wrote: On 2014-12-30 10:32:22 -0600 (-0600), Dolph Mathews wrote: The default behavior, rebasing automatically, is the sane default to avoid having developers run into unexpected merge conflicts on new patch submissions. Please show me an example of this

Re: [openstack-dev] [all] Proper use of 'git review -R'

2014-12-30 Thread Dolph Mathews
The default behavior, rebasing automatically, is the sane default to avoid having developers run into unexpected merge conflicts on new patch submissions. But if git-review can check to see if a review already exists in gerrit *before* doing the local rebase, I'd be in favor of it skipping the

Re: [openstack-dev] [all] Proper use of 'git review -R'

2014-12-30 Thread Jeremy Stanley
On 2014-12-30 09:46:35 -0500 (-0500), David Kranz wrote: [...] Can some one explain when we should *not* use -R after doing 'git commit --amend'? [...] In the standard workflow this should never be necessary. The default behavior in git-review is to attempt a rebase and then undo it before

Re: [openstack-dev] [all] Proper use of 'git review -R'

2014-12-30 Thread Jeremy Stanley
On 2014-12-30 10:32:22 -0600 (-0600), Dolph Mathews wrote: The default behavior, rebasing automatically, is the sane default to avoid having developers run into unexpected merge conflicts on new patch submissions. Please show me an example of this in the wild. I suspect a lot of reviewers are

Re: [openstack-dev] [all] Proper use of 'git review -R'

2014-12-30 Thread Brant Knudson
On Tue, Dec 30, 2014 at 8:46 AM, David Kranz dkr...@redhat.com wrote: Many times when I review a revision of an existing patch, I can't see just the change from the previous version due to other rebases. I've gotten used to this. Typically when I review a new patch set I look for my comments

Re: [openstack-dev] [all] Proper use of 'git review -R'

2014-12-30 Thread David Kranz
On 12/30/2014 11:37 AM, Jeremy Stanley wrote: On 2014-12-30 09:46:35 -0500 (-0500), David Kranz wrote: [...] Can some one explain when we should *not* use -R after doing 'git commit --amend'? [...] In the standard workflow this should never be necessary. The default behavior in git-review is

Re: [openstack-dev] [all] Proper use of 'git review -R'

2014-12-30 Thread Jeremy Stanley
On 2014-12-30 12:31:35 -0500 (-0500), David Kranz wrote: [...] 1. This is really a UI issue, and one that is experienced by many. What is desired is an option to look at different revisions of the patch that show only what the author actually changed, unless there was a conflict. I'm not sure