If you could magically confirm that a ghost inline still makes sense on the updated diff, then auto-expanding it makes more sense to me. The main utility of folding it by default would be to minimize the damage of bringing forward "stale" inlines. @avivey made a good point that this could be integrated more tightly into the "Done" state.

I used auto folding and I can honestly say - it's a mixture. When working on same group of code when I remember context - it's time saver. When I forget context - It's OK. So I guess that's for me it's 75% good.

Are people who have had chance to use the auto-folding inlines finding that they're an improvement?

In T7447#110476, @joshuaspence wrote:

In T7447#110475, @scohen wrote:

I don't know @epriestley, I found it really confusing to have my comment on a different line entirely.

+1

I'm sorry to say I don't for the life of me understand how "this feature (as it exists today) is a net improvement to Differential". See this screenshot from one of our reviews, which both hightlights the fact that the diff is terribly difficult to read, and even more important, has major issues with where the forward-moving comments appear:

At HEAD, the messages are folded individually.

I don't see any examples anywhere that have a whole inline "conversation" on an older diff. Do those conversations get folded to one line, or does each message get folded individually?

To me it seems confusing either way, but in those cases we usually over-inform. If we remove them, someone will come and complain on the other side. Are there precedents maybe in other review platforms?

In T7447#110475, @scohen wrote:

I don't know @epriestley, I found it really confusing to have my comment on a different line entirely.

I don't know @epriestley, I found it really confusing to have my comment on a different line entirely. Coupled with the "I can't mark this as done" thing, it made for a confusing experience.

The comments persist even when the code that you're talking about is deleted.

@scohen T1460 is the task for the "Done" feature.

Looking at @chad's comment, I see that we do code reviews vastly differently than you guys do. I don't think I've ever rejected an entire diff in my 3 years here.

@jparise Our thoughts on that are if an individual piece of code is "bad", the entire diff is "bad" and should be rejected as a whole - to keep things simple.

Perhaps a reviewer could flag a comment as "Changes Requested" or similar to indicate whether the comment should be inherited by future revisions (until it is marked "Done" by the owner).

@alancrisp - I'd rather have whole history of what was requested and done. That's why minimal ui for showing old done inlines is better in the long run: If I don't care, it's just one line I can skip. If I care it's visible and I can click to expand :-)

If I'm a reviewer that has previously requested a change it can be useful to see the "Done" comments. If I'm a second reviewer coming along after two or more diffs it's not terribly useful to me and serves more as a distraction from the code I'm trying to review. That seems to be the consensus amongst my team anyway.

In T7447#110375, @epriestley wrote:

As a reviewer, I think bringing "Done" comments forward is quite important: it makes it a lot easier for me to verify that they're really done. This is the #1 benefit I've reaped from this feature so far.

As a reviewer, I think bringing "Done" comments forward is quite important: it makes it a lot easier for me to verify that they're really done. This is the #1 benefit I've reaped from this feature so far.

• T7999 suggested something along the lines of the "minimal UI".
• Via IRC, "(btw, the 'moving comments over' feature has been a big hit here.)"
• Via Twitter, our heroism was recognized.

I vote for minimal ui.

I think my vote would be "minimal ui (with keyboard support)" if done comments are carried over, and "always show" if they stop where are (because while not done, it's relevant).

I'm just looking for feedback at this point, I have a "minimal" UI in a local branch, but I felt it best to get some real feedback first. So if you have an opinion, shoot!

Will comments marked as "Done" still be brought forward?

Maybe collapsing older comments when you get past some threshold similar to what is done in the section of the review and providing a per-thread "show older comments" control or something similar would make sense here?

Maybe collapsing older comments when you get past some threshold similar to what is done in the section of the review and providing a per-thread "show older comments" control or something similar would make sense here?

I'd have to agree that diffs seem much noisier now. For the way we use Differential at least, we generally find that older comments aren't all that useful and can actually get in the way depending on where they're placed (inside if blocks, for example).

In T7447#109397, @epriestley wrote:

In T1460#109396, @asteinlein wrote:

We're liking the new feature to mark inline comments as done, however, we dislike the change that makes old comments "stick" to updated diffs. This makes it much harder to read the new updated diff when there are lots of inline comments. Any plans to improve this somehow?

Can you explain your use case a little more? Why are there lots of inline comments? (See discussion earlier in this task.)

@asteinlein, would a 'minimal' UI be better for your team (see mocks above) or turning them off altogether (maybe via a keyboard shortcut) be most inline with your needs?

@asteinlein, this is the task for porting comments across diffs.

Most of the obvious/easy cases for this are implemented now, and the changes are pushed to this server. You can see an example on D12489.

Ah, I really like the "rewind" arrow.

Another pass at GhostUI. This adds a forward/backward icon to indicate if the comment is on a past or future revision.