Fossil Forum

Everything? Keeping vs Seeing
Login

Everything? Keeping vs Seeing

Everything? Keeping vs Seeing

(1) By Larry Brasfield (larrybr) on 2021-07-06 20:57:51 [link] [source]

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.

(2) By sean (jungleboogie) on 2021-07-06 21:31:18 in reply to 1 [link] [source]

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.

(3.2) By Warren Young (wyoung) on 2021-07-06 21:41:52 edited from 3.1 in reply to 1 [link] [source]

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.

(4.1) By Larry Brasfield (larrybr) on 2021-07-06 21:57:48 edited from 4.0 in reply to 2 [link] [source]

(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.

DOG \----> CAT would render as DOG --> CAT. \ \--> piggy --> piggier

. 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.

(5) By Larry Brasfield (larrybr) on 2021-07-06 21:55:55 in reply to 3.2 [link] [source]

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.

(6.1) By sean (jungleboogie) on 2021-07-06 21:59:50 edited from 6.0 in reply to 3.2 [link] [source]

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.

(7) By Larry Brasfield (larrybr) on 2021-07-06 22:04:35 in reply to 6.0 [link] [source]

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.)

(8) By ravbc on 2021-07-07 10:16:20 in reply to 6.1 [link] [source]

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):

trunk working review
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
]

(9) By Larry Brasfield (larrybr) on 2021-07-07 13:47:55 in reply to 8 [link] [source]

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.

(10) By Andy Bradford (andybradford) on 2021-07-07 18:35:24 in reply to 6.1 [link] [source]

> Can a branch be hidden and visible at different points?

Yes.  You can  use the  "fossil tag"  command to  add a  non-propagating
hidden tag to any commit you choose, for example:

fossil tag add --raw hidden e9d6469edb

Andy

(11) By ravbc on 2021-07-07 18:39:55 in reply to 9 [link] [source]

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

(12) By Andy Bradford (andybradford) on 2021-07-07 18:42:02 in reply to 3.2 [link] [source]

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

The same thought occurred to me too, however, the current implementation
of --hide  in most  interfaces is  to hide the  entire branch  (e.g. via
propagating tag), but that's not what I gather is wanted.

> You just don't get to see it in places like "fossil branch" output.

Actually, "fossil branch" only "hides"  branches that are closed, and in
fact, most CLI interaction is blissfully unaware of the "hidden" tag.

On a  more theoretical note,  I'm not sure why  one cares so  much about
hiding what one perceives to be clutter in another beholder's eyes.

As others have pointed out, having a restricted timeline view is already
possible  and  adding more  features  to  Fossil  to hide  things  seems
antithetical.

Andy

(13) By Andy Bradford (andybradford) on 2021-07-07 18:48:49 in reply to 7 [source]

> Provide a  way to  mark some  details of  the graph  as not  worth the
> attention of others unless they want to see booboos.

Please see  my response to sean  wherein I provided a  method for hiding
nodes  in a  linear branch  of development.  Fossil already  handles the
display in  the UI just fine,  it shows dotted lines  connecting the two
visible nodes where there exists hiddent content.

Basically, you can tag  any commit with the "hidden" tag  and as long as
it does not propagate will only apply to that one commit:

fossil tag add --raw hidden e9d6469edb605d

Andy

(14) By sean (jungleboogie) on 2021-07-08 23:21:54 in reply to 13 [link] [source]

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?

(15) By Andy Bradford (andybradford) on 2021-07-09 01:14:35 in reply to 14 [link] [source]

> 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

No, it  isn't currently  possible to add  raw tags or  hide a  commit at
commit time.  The control  artifacts that  you see  in the  timeline are
normally not shown if you have the Type set to "Check-ins".

Andy

(16) By sean (jungleboogie) on 2021-07-09 03:22:49 in reply to 15 [link] [source]

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.