Re: debbugs tracker builds character

[Dmitry Gutov]

On 07/20/2016 08:54 PM, Ted Zlatanov wrote:

> For me personally, if I can *see* the specific code that fixes a ticket
> inside the ticket as a commit, and click my way to the wider commit and
> then diff from before that commit against today's state of that code,
> I've built a mental map of the code that would otherwise take me a lot
> of work. That's one common workflow. Another is to view several commits
> that fix a single ticket in one place. So it's not revolutionary, just
> simpler and more straightforward for the user.

Being able to close a bug just by mentioning it in a certain way in the 
commit message and pushing that commit is also handy. You don't have to 
switch to the bug discussion and duplicate that info there manually.

> SM> How do you "update a commit"?  What does "resolve a comment" mean?
>
> Rebase or amend+force push would update a branch destructively, which in
> a pull request context should show you that a comment was for a commit
> that's no longer in the branch. Furthermore some trackers allow you to
> mark a comment as resolved (e.g. Github recently added reactions, which
> can be used as ad-hoc markup).

Even if you don't rebase, but just push a new commit to the branch upon 
review, IIRC both Github and Gitlab can see that the changes that 
started a particular discussion are no longer there (and collapse the 
comment sub-thread a no longer relevant, while allowing the user to 
expand it again if they so wish).

And on the more basic level, compared to flat discussions in mailing 
lists, having separate subthread for each part of the patch the reviewer 
commented on, is great. You can have discussion sub-threads in the 
mailing list too, but people never split their emails in pieces that small.