In Timeline in browser UI view the click on a hyperlinks fills and uses the Tag Filter Edit and Drop fields in Advanced view selection.

I have some repositories with many branches in parallel and want to compare e.g. the files of checkin G on branch Q with the files of checkin K on branch T; means I would like to ignore -while doing this- all other branches.

The Tag Filter helps to focus on one branch.

I would like to ask for the feature of having a second Tag Filter Edit field.

It should work in such a way that all is filtered as nowadays but considering the 2nd tag filter entry as OR'ed: Show me the branches which matches either the standard tag or the new 2nd tag but hide all other branches.

The 2nd edit field can remain manually filled and emptied without automation by any hyperlink click or provided as as a DropDownEdit field for easy selection of existing branch names.

Is this feasible or am I the only one who would appreciate such enhancement?

Is this feasible or am I the only one who would appreciate such enhancement?

Adding UI elements for it feasible, yes, but it sounds to me like a use case for a specific user. The timeline is fossil's single most complex bit of machinery, though, and each new way added for filtering it makes it even more so.

The 2nd edit field can remain manually filled and emptied without automation by any hyperlink click...

You can already do that via manual name selection of both branches:

/vdiff?from=branch-one&to=branch-to

If you have a huge number of branches active at once then it might help to open up the /brlist page and sort them by time, rather than trying to find them in a highly-active timeline.

Here's a related feature suggestion for implementation by someone itched by it: on the /brlist page it "should" be possible to select any two branches for diffing, similar to node selection in the timeline or George's new wiki version diff selector. Such a selection would simply send the user to the vdiff page as demonstrated above.

Thanks for the hints. Unfortunately something with the 'to' parameter to the /vdiff does not work, I get following 'Bad Request' response:

/vdiff: Missing "to" query parameter

but I typed in two existing branch names... the /vdiff seems not to understand the to parameter even when requesting it and when it is supplied.

/brlist is nice but is is not possible to select two branches for diffing .. yes, that feature would be very helpful.

Does your remark about complexity of the timeline machinery mean that there will almost never do done any changes there anymore?

Thanks for the hints. Unfortunately something with the 'to' parameter to the /vdiff does not work, I get following 'Bad Request' response:

Can you post the exact URL you're using? It need not be reachable from here, this is just to rule out any typos or whatnot.

Does your remark about complexity of the timeline machinery mean that there will almost never do done any changes there anymore?

It means that i avoid it and i offer it as a warning to anyone who naively assumes that changes to the timeline are necessarily trivial ;).

on the /brlist page it "should" be possible to select any two branches for diffing, similar to node selection in the timeline or George's new wiki version diff selector. Such a selection would simply send the user to the vdiff page as demonstrated above.

That would be a cool feature!

I tried various combinations and found that I have two challenges

1. it is not good to use any tag but it needs the tag of a branch .. as all tags look the same way it is not always easy to see which one is used as the branch. However, that is managable .. I assume the first tag in the list of tags per checkout is the one of the branch.

2. the main issue was the use of character #, which when used in an URL, needs to be written as %23 .... the dash - can remain as such and does not need to be translated into %2D.

It looks to me as if this would give me the result as expected, thanks again for the hint with /vdiff . I will be able to use it for use.

All what would be required is the possibility to select two branchnames out of the list of all branches and then transform the two into one url in correct format for /vdiff

even when /vdiff works well with two branch names it does this only with the latest checkout.... my vision with the 2nd edit field for the filter was more similar to hiding all other branches from being displayed .. but the remaining branches with all their checkins in normal timeline view.

In this regard /vdiff does not do what I had in mind when I published my wish for the feature request with more than only one filter item text

Could you please explain why the use of regular expressions doesn't work for you?
I mean something like src:/timeline?ms=regexp&rel&t=(th1-.*|test.*)

Thanks for the hint with regular expressions ... it is working and is (almost) doing what I want.

However, the input field is much too small to see what filter conditions I typed in .. that is much different from getting an opportunity to do the filter assembly by clicking with the mouse in a browser view. .. and where do I get help on the regular expression syntax? I did not find it from within the project view.

The tiny size of the filter edit input was not making me curious to find out if long expressions would be used out of it - but it did at least with two of my branch names when I or'ed them with the pipe symbol.

If the /brview could be enhanced to support the assembly of the regular expression statement before calling the /timeline view with that expression (in valid url syntax) then it would be all I need to work much better with my fossil projects.

I could think about a big edit field in the /brview where each click to a branch name could make it getting cumulative filled (previously using a checkbox to change from direct hyper jumps to editing the filter condition field first).

You do understand that edit boxes normally accept larger text blocks than can be rendered in their display width, right? And they normally auto-scroll their content as the cursor goes out of sight within such larger text blocks.

Given those facts, how critical do you see that enlargement being?

I could think about a big edit field in the /brview where each click to a branch name could make it getting cumulative filled (previously using a checkbox to change from direct hyper jumps to editing the filter condition field first).

A text entry field is not needed. George has already implemented a first go at interactive selection of a set of branches:

https://fossil-scm.org/home/timeline?r=brlist-timeline

When de/selecting a branch, a button which links to the timeline gets updated, and clicking it launches the timeline with the appropriate regex parameters. It doesn't do wildcard selection, but that's something which a niche-case user could do manually by editing the resulting link.

This sounds to become a really nice and useful feature and will my life with fossil make a little easier.

How many branches can be selected into the regex supporting button? Is it restricted to one or two or can some more be selected?

yes, that I know very well. But if my branch name has e.g. 20 characters length and I can see only 11 of them then it is very error prone. Combining some of them into one regex it is even more error prone that at the end there might be some typo at the beginning of the text, which is not visible. The capability to 10-fingered writing blind is very helpful indeed but regular expressions are usually contain several unusual characters like punctuations, which have a higher rate of errors. I prefer to see and read what I wrote instead of posting errors and have to restart from the beginning again and again until all is right accidentally.

In such case it is easier to keep a text editor open in parallel, type the expression and then copy-paste it into the tiny edit field; but convenience is something else.

How many branches can be selected into the regex supporting button? Is it restricted to one or two or can some more be selected?

With a little patience, you can select all of them (but that has the same effect as selecting none, since the default is to show all branches).

I'm curious: what are the most awkward names that people are actually using for branches or tags? Does anybody use any of special symbols within branch names: ```

• . | ^ " < > ' ( ) [ ] ```

Does anybody use Unicode within branch names?
Should we worry about all the above?

I think Fossil should handle those names fine for its own use. But problems arise when you try to export to Git.

I am using # - _ = + ~ as special characters, avoiding Spaces

* . | ^ " < > ' ( ) [ ]

Should we worry about all the above?

Yes, I also think these "meta-characters" should be properly escaped when building the regular expression, since for example branch names containing a . (dot) are fairly common in Fossil, but an unescaped . (dot) means "any character".

This could work in a similar way to the MDN sample to escape Javascript regular expressions (see function escapeRegExp(string)), but adapted for Fossil. The list of "meta-characters" for the Fossil regular expression dialect is summarized in Fossil grep vs POSIX grep, section Regular Expression Dialect.

However, not sure if this row:

\c → Character c where c is one of {}()[]|*+?.\

should also include ^ and $? But note that <, >, " and ' do not need to be escaped (except with encodeURI[Component]() for proper HTTP transmission).

Besides the incorrect escaping of string literals to be reused in regular expressions, as mentioned in the previous post, there's another thing that's bugging me:

The "bold" hover-style expands the "Branch Name" column if the mouse cursor is moved over a long branch name, triggering relayout of the whole table, resulting in the checkboxes and other columns to jump to the right. It's not as bad as elsewhere†, but since the "bold" hover-style doesn't add any "readability value" (i.e. it doesn't highlight the full table row and make it easier to see which cells are from the same row), and is also inconsistent with the rest of the Fossil web UI, I think it should be removed?

† The new /fileedit and/or /wikiedit UIs still have jumping controls: for one of the drop-down lists, when a new entry is selected, another control is immediately shown or hidden, and the relayout of the centered row causes the active drop-down list to jump away from under the mouse cursor, so besides the general confusion caused by the relayout, there's no luck with quickly changing the selection again, either ...

... but since the "bold" hover-style doesn't add any "readability value" (i.e. it doesn't highlight the full table row and make it easier to see which cells are from the same row), and is also inconsistent with the rest of the Fossil web UI, I think it should be removed?

I was wrong here, the "bold" hover-style is also applied if the mouse cursor is over another column than "Branch Name" in the same row, which may help to oversee which columns belong to the same row.

But, I still feel that jumping elements are bad for usability!

Consider the following branch list for a repository with only a few similarly-named branches:

Branch Name         Last      Check-ins ...
                    Change
branch-name-0  [ ]  0.0 days  ...
branch-name-1  [ ]  1.0 days  ...
branch-name-2  [ ]  2.0 days  ...

Each time the mouse cursor is moved over a checkbox to click it, that aimed-for checkbox will instantly jump to the right, because applying the "bold" hover-style to any of the similar branch names causes the "Branch Name" column to expand, and the whole table to reflow.

I think this should really be changed. If the hover-style is deemed necessary, maybe it could modify the background color, similar to the "Most recent Forum threads" page?

But, I still feel that jumping elements are bad for usability!

Agreed, but when is sat down to implement your suggestion of changing the background color instead, i'm unable to reproduce this:

Each time the mouse cursor is moved over a checkbox to click it, that aimed-for checkbox will instantly jump to the right, because applying the "bold" hover-style to any of the similar branch names causes the "Branch Name" column to expand, and the whole table to reflow.

In both Chrome and FF all of the layout stays stable except for the text being bolded, and the bolding does not change the text size enough to change the table row height, so nothing shifts except the size of the branch name.

Which browser are you seeing reflow in?

Thanks for looking at this!

I can see this with Chromium on Windows, but just verified the same behavior with Firefox on Ubuntu.

You may not encounter this on a tablet, since there's no mouse pointer hover events, and maybe on some systems, normal and bold text have the same width?

But you need to try a long branch name, for example, in the Fossil Branch List, try andy_bradford_ssh_imporvement_patch_1. (Hm, isn't "imporvement" spelled with a double "o"?)

Or, this sample script:

fossil init sample.fossil
fossil open sample.fossil
fossil br new release-version-1.0.0 current
fossil br new release-version-1.1.0 current
fossil br new release-version-1.2.0 current
fossil ui --page brlist

Besides the incorrect escaping of string literals to be reused in regular expressions, as mentioned in the previous post

That was resolved a couple of days ago: Richard extended the timeline to be able to treat a list of branch names (comma-separated) as-is instead of treating them like regexes.

The "bold" hover-style expands the "Branch Name" column if the mouse cursor is moved over a long branch name, triggering relayout of the whole table, resulting in the checkboxes and other columns to jump to the right.

That's now resolved. All skins use the same color as the currently-selected timeline row except for the xekri skin, where that color is not distinguishable from the page background.

The new /fileedit and/or /wikiedit UIs still have jumping controls: for one of the drop-down lists, when a new entry is selected, another control is immediately shown or hidden, and the relayout of the centered row causes the active drop-down list to jump away from under the mouse cursor, so besides the general confusion caused by the relayout, there's no luck with quickly changing the selection again, either ...

Patches are welcomed. We can't know a fixed size for all of the UI controls, in particular the dropdown list because it contains arbitrary filenames. When making a selection, the list closes anyway, so there's no possibility of immediately selecting the list without moving the mouse. While i agree that UI controls moving out from under a user provide, as a rule, a poor UI experience, in this case the drop-down moves regardless of whether or not the overall page layout is changed by the selection, so it has never bothered me in practice.

I just got the most recent built for Windows [9322a0bc20] from the download page and tested the /brlist (Branches web page) feature with multibranch selection. I am amazed how nice and good this is now looking like to me. It is definitely useful for my work!

There is always something to further improve a bit more, here are some of my ideas for the Branches UI view /brlist:

• Add a <Tag Filter> capability similar to what is already available in the Timeline view. My use case: "Select all branches by machine type" or another time I would like to "Select all branches from one plant" - a button to carry out the selection additions on top of the already selected branches
• Add a button to <Select All branches>. The use case for me is: "Select All but trunk" to show me the specials without the multiple development steps
• Add a button to <Clear All selections> to allow restart without having to modify the URL (which is not so nice on a tablet computer)
• Add a selection checkbox also behind the "merged into name" column to easy searching and selection of that branch also

An argue about "filter already in timeline view" is not valid as the branch selection list shall allow selection accumulation before execution by the View N branches button

• An additional column with a unique list of all non-propagating tags which are used in that branch (ordered as they were introduced in timeline by time)
• The above tag filter capability enhanced by another button to search and add the containing branches also for those contained non-propagating tags

EDIT: Instead of an additional column for non-propagating tags it might be a better way to add a checkbox "Non-propagating tags" similar to the "Files" checkbox in the timeline view. The list of non-propagating tags can have each another checkbox to add the tag to the selection accumulation tag list for the "n branches view" button.

• in the /taglist view each tag could get a checkbox and a button "view branchlist (/brlist) with n tags" could change into the /brview with the checkboxes checked in all branches which contain one or more of these tags.

One use case could be to check the "release" tag in /taglist and get the list of branches which are no development-only-branches in /brlist and then change into the /timeline view to only inspect the various release histories on all branches which released anything (the complete branch timelines and not only the few affected check-ins).

The "bold" hover-style expands the "Branch Name" column ...

That's now resolved.

Thanks, no more jumping elements. That /brlist is critical infrastructure to me, also on 3rd party repositories, where I can't patch the Fossil executable, so I'm glad this is fixed upstream.

We can't know a fixed size for all of the UI controls, in particular the dropdown list because it contains arbitrary filenames.

Hm, probably variable-width controls should be in their own row...? Anyway, I think the example with the controls jumping right after drop-down list selection I had in mind was /fileedit → Preview → Preview Mode?

Another small glitch I've just noticed:

During loading and initial page layout of the Fossil Branch List page, a submenu item labeled "Timeline" appears, on the left of the "Use Branch Colors" checkbox, which disappears immediately after page loading and layout have completed.

What about a search capability addition similar to what is available in timeline view also for the /brlist branches view!? Some of my lists are long and that would support me a lot.

Another hint: switching on the colors unchecks all boxes which were checked at that moment. Recommendation: Switch colors first and then stay with that setting

How is it possible in the list of branches to see which of them are hidden? To see the Branch Color is available and also where a branch got merged into.

Feature request:

The status closed is shown but there is no status hidden anywhere. Can this be added somehow? For example the text color of Last Change could be shown in gray for hidden branches.

Private branches would probably also make sense to get their status shown somehow - but because I did not use them yes, this remark is only to not forget them.

(Changing the checkbox to Use/not-use Branch Colors unchecks all branch selections; a bug or a feature?)