One of my clients settled upon Git several years ago, so I had to learn (some of) it. It was a struggle at times, but with some help, cheat sheets, and recourse to the guy who had advocated it, I came to appreciate (some of) its virtues.

I have also followed the "debate" regarding Fossil's "keep everything" approach versus Git's "keep and show only what history you like" approach. I still find myself sympathetic to both. But as I read the latest, level-headed comparison from Richard, while pondering why I like the "hide what need not be seen" feature(s) of Git, it suddenly occurred to me that there is a compromise that might be satisfying to many who prefer Git for that reason (and who are not compelled by need for a Bazaar style of contribution.)

It would be nice to be able to mark nodes on the branch graph as having lower visibility priority. I know I have stupid little check-ins at times, and I regret cluttering up the graph seen by others with little stuff, blooper fixes, purely local dead-end branches, and intermediate progress points that do not really represent anything interesting from a higher vantage point. I do not mind that such stuff is there; (It helps maintain some humility.) But I dread creating a mess others must see.

So, the feature suggestion is: Permit nodes to have downgraded visibility so that, at the default timeline visibility setting, nodes do not show up and branches with enough less-visible nodes also do not show up. The history would still be there, in all its glory (and embarrassment.) Needless clutter would be less bothersome, and it would (maybe) be attractive to rebase fans.

The default timeline visibility is user configurable via cookie. This option would override the cookie?

If you dare engage with those who want to hide everything, you can present with this url as an example:

https://fossil-scm.org/home/timeline?advm=1&ms=exact&n=200&ss=m&t=trunk&udc=1&y=ci

Hides everything that's 'not on trunk'. It's doubtful to do what you and they want, but it's a way to not clutter up the timeline view for you.

Maybe there could be a 'trunk only' button near the check-ins drop down, but you can already click on the trunk link in any check-in and easily filter that way.

(1.1 ASCII art fixup)

What I'm suggesting is that there be a new tag, or an expanded use of some existing tag, that sets the "visibility_priority" of node to lower than its default, "always visible". The timeline GUI would have a setting for "visibility_priority" threshold. Nodes with lower visibility_priority than that threshold would vanish, with graph edges changing to match.

For example: DOG -> pig -> CAT would render as DOG -> CAT.

. The 'pig*' nodes have lower visibility_priority. In the upper case because it was merely adding in an unintended extra file. In the lower case, because it was an ill-fated performance enhancement that failed because it was ill-conceived.

What would you expect to occur differently than you get with the currently-available alternative:

  $ fossil amend --hide current

You seem to be asking for multiple levels of hiding, but how does that affect the CLI and web UI? Are you suggesting that people would dial the timeline to, say, 68% visibility or something?

What might make more sense is:

  $ fossil ci -m 'my highly-dodgy new feature attempt' --branch my-experiment --hide

The "ci" command already takes some of the "amend" flags, so why not --hide?

You can still work with a hidden branch. You just don't get to see it in places like "fossil branch" output. You have to know it's there and ask for it by name, much as with a hidden WiFi SSID.

Warran, See #4. It is selective visibility, rather than all or none, and it applies to nodes rather than whole branches.

As I understand some of the Git appeal, it allows selective simplification of the descendency graph, by manipulating the apparent history. My idea is to get the same benefit as simplification, without the lyingfact-alteration.

Can a branch be hidden and visible at different points?

Initially I'm really confident in something-great-feature and I want all to see it, but I slack off and make lots of typos and things aren't building/working correctly. I want to hide the next three commits but reveal my masterpiece in commit 5 but still in my own branch. Can I hide/unhide like that?

Also, from the discussions it seems people want to give a nearly perfect branch to those who will review their work and merge to trunk. Fossil now has patch, but don't know if that's sufficient enough for those who only want to carry around their accomplishments and not be reminded of their sins and mistakes.

Can a branch be hidden and visible at different points?

Sort of. Dimming a node belonging to a single line of development just suppresses its display while joining the incoming and outgoing edges. Dimming a node from which more than one edge emanates is a no-op unless one emanation would be dimmed because all of its nodes are dimmed.

Another way to view my proposal: Provide a way to mark some details of the graph as not worth the attention of others unless they want to see booboos.

For review, it avoids wasting the reviewers' time.

See #4.1 (now clearer with a missing edge rendering as I intended.)

fossil tag add --raw hidden e9d6469edb605d

This is pretty cool!!

https://imgur.com/a/BEFxLv8

There are six commits in the newfeature branch, but you see only two.

There are four commits between the first and last, plus I closed the the branch after I merged to trunk, but you can't see that either.

My only critique would be to have the command be a little less obtuse. Not sure what that would look like just yet...

Basically, you can tag any commit with the "hidden" tag

Can you do that at the time of the commit? My test above was done after the commits, so I have several Edit [939c492a43]: Add "hidden". messages

Also, this doesn't seem to hide the commit messages in the cli, and the edit messages are also present. Know anyway to hide those commits who have been tagged with hidden?

The control artifacts that you see in the timeline are normally not shown if you have the Type set to "Check-ins".

yes, that's true for the UI on the web, but I'm also interested in the timeline view on the cli. The edit messages are present in the timeline cli view.

from the discussions it seems people want to give a nearly perfect branch to those who will review their work and merge to trunk

Isn't it the same as creating a new trunk-based "review branch" with merged in all the changes from the working branch, and at the same time hiding the working branch? Something like this (when greyed-out means hidden):

ALL: [
T1: circle rad 40% thickness 1.5px fill white
arrow 40%
T2: circle same
W1: circle same color gray at dist(T1,T2) se of T2
arrow 40% color gray
circle same
arrow same
W2: circle same
arrow color gray from T2 to W1 chop
R1: circle same color black at .5 s of W1
R2: circle same at W2+(0.3,-0.5)
arrow same from W2 to R2 chop
arrow from T2 to R1 chop
arrow from R1 to R2 chop
T3: circle same at dist(T1,R2) e of T2
arrow from T2 to T3 chop
arrow dashed 0.03 from R2 to T3 chop
layer = 0
"trunk" above at T1.n
"working" below at W1.s
"review" below at R1.s
]

The difference between what I propose and what your graph suggests is that I would not allow any nodes to be displayed that did not represent the state of the repo at the time of their creation. There would be no history revision, just selective hiding of some history details.

Well, hiding some commits is already possible AFAIK, but people want a "history cleaner tool". My proposal do just that, I think.