[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] Using Gerrit to see diffs between changesets
|
On 9 Oct 2009, at 02:05, Shawn O. Pearce wrote:
Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
I spent a while reviewing (and coming up with comments for) this
changeset:
http://egit.eclipse.org/r/#change,41
However, whilst I was doing that, another one appeared. Is there
any way
to see what (a) files I've seen already,
Not easily in the new patch set, no. The little green check means
you've looked at this revision of this file, but doesn't help you
much between patch sets when a file hasn't changed.
It's worse when they're a bunch of new files, and minor changes keep
getting added but it looks like it's a reset of everything :-)
and (b) diffs since the last
time I saw the changes?
Open the first file of the new patch set, expand the History foldy
at the top, click the prior patch set in the left hand column.
That does it on a file-by-file basis. Stepping through and doing that
for many files is almost as painful as just looking at many files. Can
we have something which does a diff across all of the files in a
changeset? To be honest, a 'diff everything' would be useful too, and
is the way I usually work in code reviews rather than on a file-by-
file basis.
I think these could
easily be applied after the branch has been committed to master
(and then
subsequent changesets show them from there) which would at least
make my
life at reviewing them slightly easier ...
Robin and I have a somewhat conservative policy when applying code,
we want to apply as perfect of a change as we can reasonably get.
If there are problems known up front with something, we want to
fix those before we apply it.
That seems reasonable. However, given that Git has wonderful
branching, committing, and the ability to re-write afterwards, and
with the knowledge that each time a new patchset comes in it's a
different tip anyway, can we not find a way of committing a bunch of
incremental versions of the same changeset, then collapse (squash?)
them down into a single commit when they hit the branch itself?
Doesn't Gerrit treat each change as a branch anyway?
Alex
