Bug 381520 - [historyView] Enable custom selection of branches/tags/refs to filter commits to be shown
Summary: [historyView] Enable custom selection of branches/tags/refs to filter commits...
Status: RESOLVED FIXED
Alias: None
Product: EGit
Classification: Technology
Component: UI (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P3 enhancement with 4 votes (vote)
Target Milestone: 5.6   Edit
Assignee: Tim Neumann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 459184 492674 536275 547812 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-06-04 02:21 EDT by Matthias Sohn CLA
Modified: 2019-11-12 01:41 EST (History)
14 users (show)

See Also:


Attachments
too many merge arrows (81.03 KB, image/png)
2019-07-18 07:52 EDT, Andrey Loskutov CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Sohn CLA 2012-06-04 02:21:43 EDT
At the moment (EGit 2.0) the history view can either display the version graph for all branches or for one branch. 

Often there are many branches in a repository. Then it may happen that these two choices either show too many or too few branches. Hence it would be useful if the user could also manually select branches, tags, additional Refs from the list of all branches/tags/additional refs which should be used as start points for the RevWalk.
Comment 1 Frank Jakop CLA 2013-06-26 07:13:21 EDT
I agree, this would be *very* useful as it often happens to merge two branches, on which a specific file was concurently changed. For the understanding of the aims the developers had (and so for a successful merge) it is necessary to look at the file's histories on both branches.
So only the merge-from and merge-into branch are neede to be seen. In combination with filtering the commits of this specific file it would ease up a developer's life.
Comment 2 Markus Keller CLA 2014-02-19 08:51:32 EST
(In reply to Robin Stocker from bug 359406 comment #1)
> In the repositories view, you can right-click on a branch and select Show In
> > History. See bug 381520 for selecting a branch in the history view.

Note that "Show In > History" from a branch in the Git Repositories view only selects the HEAD commit of that branch if the History view is configured to show all branches.

See also bug 360868 comment 3 for a slightly different solution (temporarily change the branches shown in the History view when the selected branch/tag/commit is filtered out from the History view).
Comment 3 Matthias Sohn CLA 2016-04-29 18:18:10 EDT
*** Bug 492674 has been marked as a duplicate of this bug. ***
Comment 4 Felix Dorner CLA 2017-03-10 05:54:29 EST
I would like the selection to be pattern/regex based, for example to always show all branches that have a given prefix in common.
Comment 5 Matthias Sohn CLA 2019-06-05 06:45:27 EDT
*** Bug 547812 has been marked as a duplicate of this bug. ***
Comment 6 Andrey Loskutov CLA 2019-06-21 17:38:59 EDT
(In reply to Matthias Sohn from comment #5)
> *** Bug 547812 has been marked as a duplicate of this bug. ***

Adding here my original comment:

Reason for me to want this feature: we have a huge repo with ~8000 branches. Usually we have two most interesting branches: "current feature" and "master" branches, where we have either the current team development and the whole product development states. Today I can't just say: show me "master" and "my feature" branch only, to see how my current state and master are diverged or if I want to cherry pick something from master and vise versa, because due the massive amount of commits on other 7998 branches. 

Basically today I'm always use "single branch" mode, because the number of branches/merges makes the history view with *all* branches shown unusable.

So ideally we could have a name based filter for the history view where I could say "show only matched branches". Something similar to the Package/Project Explorer filtering by name (just the opposite - not hide, but show matched branches). One could add/remove patterns and one can enable/disable that thing completely.
Comment 7 Thomas Wolf CLA 2019-06-30 16:08:28 EDT
*** Bug 536275 has been marked as a duplicate of this bug. ***
Comment 8 Thomas Wolf CLA 2019-06-30 17:04:45 EDT
*** Bug 459184 has been marked as a duplicate of this bug. ***
Comment 9 Thomas Wolf CLA 2019-07-06 14:18:39 EDT
@Andrey: while commit https://git.eclipse.org/r/#/c/145568/ (for bug 360868) doesn't implement filtering, I think it should already help with your use case. In single-branch-mode, selecting the other branch in the git repositories view would make the history view show both branches.

A name filter is quite a bit of UI work.

What should the view do if the scope is restricted to a file/folder that doesn't exist on the selected branches?

Should HEAD always be included, even if not selected by the filter?

One probably would also like to persist filter expressions (per repository) so that they can be re-used.

Even with filtering branches merged into the selected ones would still be shown.
Comment 10 Andrey Loskutov CLA 2019-07-18 07:52:55 EDT
Created attachment 279333 [details]
too many merge arrows

(In reply to Thomas Wolf from comment #9)
> @Andrey: while commit https://git.eclipse.org/r/#/c/145568/ (for bug 360868)
> doesn't implement filtering, I think it should already help with your use
> case. In single-branch-mode, selecting the other branch in the git
> repositories view would make the history view show both branches.

See the attached picture - I don't see 5 commits on other branch because we have gazillions of merge arrows between.

> A name filter is quite a bit of UI work.

I have someone to do this work :-)

> What should the view do if the scope is restricted to a file/folder that
> doesn't exist on the selected branches?

Same as in single branch mode, but if it would be executed once for every branch.

> Should HEAD always be included, even if not selected by the filter?

TBD. I would assume this is proposed as default, but could be changed by user to hide, if I only want to compare two other branches.

> One probably would also like to persist filter expressions (per repository)
> so that they can be re-used.

Sure.

> Even with filtering branches merged into the selected ones would still be
> shown.

My point (and strong requirement is) to have no arrows at all, see attached picture why. I assume that this is not everybody requirement, therefore I would expect the implementation would allow to toggle this on/off.

we want git log --first-parent does (for N branches selected by user), see what I mean here (for single branch):
https://saraford.net/2017/03/18/how-to-use-git-log-first-parent-to-only-view-commits-that-happened-on-a-given-branch-077/

This "first parent only" button is something that I wish anyway, so if we are going to implement the "show N branches only" feature here, we can reuse same code / UI mode too.

Summary:
1) We want "log --first-parent" support for the history view in JGit/ Egit
2) We want "show N branches only" selection mode for EGit UI
3) "show N branches only" can be implemented without "log --first-parent" support
4) My strong requirement / wish is that with both 1) and 2) we can have something useful for us, where "show N branches only" as used together with "log --first-parent".
5) Any pointer where to start implementing "log --first-parent" support are welcome. 

Tim will create a dedicated bug for this in JGit and another one to add a button/option for this in EGit. He will also drive the UI for branch selection etc.
Comment 11 Tim Neumann CLA 2019-07-19 07:57:27 EDT
(In reply to Andrey Loskutov from comment #10)
> Tim will create a dedicated bug for this in JGit and another one to add a
> button/option for this in EGit. He will also drive the UI for branch
> selection etc.

Actually, I just found out, that JGit already supports first parent  (org.eclipse.jgit.revwalk.RevWalk.setFirstParent(boolean)), so no need to create a bug in JGit.
Comment 12 Thomas Wolf CLA 2019-07-19 09:09:50 EDT
Yes, --first-parent has been implemented recently. Just be aware that it may give (perhaps) surprising results in combination with path filtering.

Consider the history

             m  b
   o--o--o---o--o master HEAD
       \--o-/
          a

HEAD = master -> b
a adds a new file x
m brings that new file into master
b changes x

git log -- x                gives b-a
git log --full-history -- x gives b-m-a
git log --first-parent -- x gives b-m

The first is what you currently get in the EGit history page.
Comment 13 Tim Neumann CLA 2019-09-02 05:47:15 EDT
(In reply to Felix Dorner from comment #4)
> I would like the selection to be pattern/regex based, for example to always
> show all branches that have a given prefix in common.

I'm currently working on this and wanted to use the ? and * pattern style common in eclipse preferences (e.g. UiResponsivenessMonitoring or Java TypeFilters).
Does anybody know if there is a class/method that can match strings against this kind of pattern somewhere in eclipse code, which i could use?
I don't really want to implement this again.
Comment 14 Thomas Wolf CLA 2019-09-02 05:55:34 EDT
Two possibilities off the top of my head:

* org.apache.tools.ant.types.selectors.SelectorUtils.matchPath(String pattern, String str, boolean isCaseSensitive) from org.apache.ant 1.10.5. (Study that code; there are more efficient ways.) Supports **.
* org.eclipse.jgit.fnmatch.FileNameMatcher, which is used elsewhere to match branches (for instance in org.eclipse.jgit.api.DescribeCommand). No support for **.
Comment 15 Eclipse Genie CLA 2019-09-10 10:56:24 EDT
New Gerrit change created: https://git.eclipse.org/r/149270
Comment 16 Eclipse Genie CLA 2019-10-23 07:42:28 EDT
New Gerrit change created: https://git.eclipse.org/r/149270
Comment 17 Eclipse Genie CLA 2019-11-12 01:05:03 EST
Gerrit change https://git.eclipse.org/r/149270 was merged to [master].
Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=16f145f4a8b8a76331e8d2c94fce4bdf01e777a5
Comment 18 Thomas Wolf CLA 2019-11-12 01:28:27 EST
Thanks Tim (and Advantest :-)