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