On Tue, Dec 30, 2014 at 11:24 AM, Jeremy Stanley 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 what the au
On Tue, Dec 30, 2014 at 9: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
> beha
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 i
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 s
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 t
On Tue, Dec 30, 2014 at 8:46 AM, David Kranz 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 and make sure th
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 ar
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 sub
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 reb
