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
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
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
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. The
git-review documentation mentions this issue and suggests using -R to
make life easier for reviewers when submitting new revisions. Can some
one explain
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
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
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
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
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
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
10 matches
Mail list logo
