I hope what I am proposing is not already implemented: I searched, but couldn't find how to do it. (Edit, I'm using gitg 3.30.1)
Often I find myself comparing files between two non-consecutive commits (e.g two branches, or specific commits in the same or different branches). Not just changes from one commit and the previous.
This is useful to see precisely what changed among two commits that are known to work in specific ways (e.g. two tags). It is a sort of bisect, but with less hassle.
I think the feature I'm proposing, along with #202, are important together to enable a smoother way to inspect changes between commits in the same or different files.
Definitely interesting, but we need how to implement it.
I think a contextual menu "Compare with branch..." would be enough. Then
history will show only the commits between selected commits.
I don't know about gitg codebase, so I cannot propose an implementation
strategy right now, but I can definitely explain my idea regarding UX.
In my mind, this is just a special case of showing the difference of a file.
Normally you have the history of commits as a list with ONE entry selected,
and the diff shows the changes introduced by that commit.
In my scenario, one could right-click another commit in the history tree
and select an entry like "compare with this commit".
This would trigger a selection of TWO lines in the history tree. Whenever
two entries are selected, the diff would show the diffs between those
commits instead of the diff with previous commit. To "exit" this mode, it
would be sufficient to click another commit in the history tree.
To make this more explicit, this is just a generalization of the current
behavior: say that you have commits
A -> B -> C
Currently, if you select C, you see the diffs with B.
In my scenario, you could select (even with ctrl+click, as common with
multi-selection lists) C and A, and see the diffs.
Having one commit selected, say B, is just as selecting that commit and
implicitly having the previous commit selected, that is B and A.
But we need still more, greyed and disable intermediate commits to
understand the diff is from one commit to the other.
Personally I don't think it would be necessary a particular status
indication, as it would be sufficient to see if one or more commits have
been selected in the history tree. Maybe, just to avoid confusion in the
case of two entries selected not being in the same page, a label or color
could be written somewhere (e.g. change the background color of the
selected commits).
We need to a way to go back to normal history view. Well, maybe this needs
a whole new view.
I think it's sufficient to click another commit in the tree.
and a new view were we pass the calculated diff (I can explain you the
details) will work.
I think my workflow could be simpler even in implementation, but I'm very
open to critics. Even tips on coding so it will take less when I'll give it
a shot.
Hi @aday, Could you give us some insights(maybe a mockup) on what would provide the best user experience regarding this issue? @albfan, and @akiross suggested interesting ideas and I would really appreciate it if you let me know your opinion on this, a mockup would be very helpful to have a better idea of what my workflow would look like while implementing this feature, as I'm a GSoC Intern and this is part of my project.
Hi @albfan, I thought maybe we could create a new compare dialog for comparing two different commits, something like this
Maybe in the "Compare Commits" dialog above, we would have two combo-boxes each one gets the commits from our commits model in gitg, also maybe we could add more options to it for different branches.
Also if the user has already selected one or two commits using the "ctrl+click" and hit the "compare" button, the commits would be already loaded by default inside the combo-boxes. What do you think about this? I'm looking forward to hearing you thoughts, and if this gets your approval maybe then we could mention anyone from the design team to confirm with us the design
@mahmoudkhalil11 Looks like you're not getting much feedback, so I thought I'd share some ideas based on my experience.
Instead of having a separate dialog for selecting commits, can it be done so that several commits can be selected in the history view and the combined diff is displayed below (same as normal diff?) I think this would be the most natural behavior for most users.
Loading thousands of commits into a combo box may be slow and how would the user find the right commit? History view already displays all the relevant info.
Adding the compare button to the title bar may achieve your goals, but what would we end up with if everyone added their button? I hope you can get a UI designer involved, but I get a feeling that no one cares about gitg at this point.
If I may interject, I think that the best option would be to provide a
"Compare with" entry in the contextual menu of the commits.
Allowing to select multiple commits in the history view might be
misleading and it requires to give an answer to the following question:
can the user compare more than 2 commits at once?
If yes, how to implement a comparison between N commits? is that
implemented with an N-way diff? I can understand 3 commits being compared,
maybe 4, but not 10 (would it even fit the screen?)
In this case, a cap might be imposed and that feels a bit arbitrary. Also,
N-way diff might be hard to implement.
If instead only 2 commits can be compared (the most common use case), then
multiple selections might be misleading because a user would expect a
selection to work with an arbitrary number of elements in a list (typical
Ctrl+click behavior).
I propose to introduce an entry "Compare with this" in the contextual menu
when user right clicks on a commit on the history. If the right click is
done in the currently selected commit, then it's grayed out. If the right
click is on any other commit, allows to compare the code of the selected
commit and the clicked one.
Thank you for your feedback, it's much appreciated.
Instead of having a separate dialog for selecting commits, can it be done so that several commits can be selected in the history view and the combined diff is displayed below (same as normal diff?) I think this would be the most natural behavior for most users.
Yes, I get your point, this what I've implemented so far. So whenever 2 commits are selected the DiffView would show the diff between those two commits.
However there are other cases, for example comparing two branches together, or comparing two different commits from two different branches. I see this implemented in gitlab as a separate compare view under the repository menu on the left. So maybe as @albfan suggested in his comment this might need a new separate view like the History view or the Commit view.
If instead only 2 commits can be compared (the most common use case), then multiple selections might be misleading because a user would expect a selection to work with an arbitrary number of elements in a list (typical Ctrl+click behavior).
I propose to introduce an entry "Compare with this" in the contextual menu when user right clicks on a commit on the history. If the right click is done in the currently selected commit, then it's grayed out. If the right click is on any other commit, allows to compare the code of the selected commit and the clicked one.
I guess the contextual menu entry would be more appropriate here in our case, I'll add it as well. However, I think "ctrl+click" might be a faster workflow for the user, also as you've mentioned, it's the most common use case to compare two commits at a time.
Currently in my code, the user is only allowed to select two commits at a time, and whenever the user tries to select a third commit, the previously selected commits get unselected and only this commit(the one that was going to be selected) is selected.