Bug 577518 - The history don't present affected files for some merge commits
Summary: The history don't present affected files for some merge commits
Status: NEW
Alias: None
Product: EGit
Classification: Technology
Component: Core (show other bugs)
Version: 5.13   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-29 06:29 EST by Alexandru Smarandache CLA
Modified: 2021-11-29 07:56 EST (History)
1 user (show)

See Also:

Attachments
An example of commit presented incompletely (45.22 KB, image/png)
2021-11-29 06:29 EST, Alexandru Smarandache CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandru Smarandache CLA 2021-11-29 06:29:34 EST 
Created attachment 287590 [details]
An example of commit presented incompletely
Comment 1 Thomas Wolf CLA 2021-11-29 07:01:38 EST 
Duplicate of bug 534142?

Basically this would need some UI for the user to say which diff relevant to which merge parent to show, plus some indication which diff was shown.
Comment 2 Alexandru Smarandache CLA 2021-11-29 07:44:04 EST 
Yes, it seems to be the same problem.
For example, for a commit of type: merge "branchA" into "branchB", the list of affected files for this commit is displayed, even if it cannot be compared to the previous version. I would like the list of affected files to be displayed for these commits as well.
Comment 3 Alexandru Smarandache CLA 2021-11-29 07:44:26 EST 
Yes, it seems to be the same problem.
For example, for a commit of type: merge "branchA" into "branchB", the list of affected files for this commit is displayed, even if it cannot be compared to the previous version. I would like the list of affected files to be displayed for these commits as well.
Comment 4 Thomas Wolf CLA 2021-11-29 07:56:40 EST 
Contributions are always welcome. See [1] for some guidelines.

Implementing this is quite a bit of work, though. The UI should be unobtrusive and also work well if we ever add searching in that file list for a particular file name (there is another issue somewhere about that). Then the code that computes this file list needs to be made aware of the choice (parent index).

Getting the content menu operations to work may then take additional effort; most are currently hard-wired to work only well with a single parent.

[1] https://wiki.eclipse.org/EGit/Contributor_Guide