Settings and activity
3 results found
-
36 votes
An error occurred while saving the comment An error occurred while saving the comment 
Sergio Navarro
commented
In summary only because you can you shouldn't show all the info you have to the user. It is more helpful to the user you give the relevant info he needs for the task it is going to do and add options to show the detailed info only when he needs it because needs further investigation of a change inthe code.
An error occurred while saving the comment Sergio Navarro
commented
Sorry for the late answer I haven't found a moment till now to answer.
I didn't said I want to compare the branch head with the master head because as you said "Comparing the branch head to the master head will only work if all your merges come from 'main'",
What I want isto compare by default with the head of the parent branch (this is not the same that always compare with main). Futhermore, I would prefer leave it as a default option but leave it open to allow the user who asks the revision to set to which branch it has to be compared (it would be the one on which he wants to merge the his branch).I totally agree with Pablo Sanchez I don't need info of what changes come from a merge. At least I would like to have the option of hide this information. In order to don't see lines merged in a different color and to skip also this lines when moving to the next and previous change through the buttons in the IDE.
Our case are real circumstances, all the team is doing code review. In fact, their complains are not only related with the fact you have to see merged changes together with changes to review when they happen in the same file.
More complains start every time a code review has more than one iteration of question answer with changes in code between reviewer and author of code. While this is a piece of cake when you use Bitbucket (maybe because it cannot do it better it shows you just what you are more interested in). Plastic instead shows you the previous code. Yes I know you have a link to see the new code but it is not clean, it breaks the focus of the reviewer. If you need another iteration of answering-modification of code-review then review turns even more strange. You need to be thinking every time what code are you viewing (the old one, the first fix after first review?, the last one?)
You simply need the code in the heads of the two branches to merge in the screen, if you don't have both in screen most likely is you need extra clicks to continue with your reviewSergio Navarro
shared this idea
·
-
105 votesSergio Navarro
supported this idea
·
-
6 votesSergio Navarro
supported this idea
·
Furthermore, plastic fails some times to detect merged changes and mark them as branch changes when indeed they are merged changes.