I'm not following all the details here but it sounds like your intended usage is mostly to hide branches that are considered mistakes. My intended use is different. I like to commit often and thus end up with many commits that are useful to me in debugging, cherrypicking etc. but not interesting in terms of the timeline. Say I'm refactoring a schema starting with node A and finishing on node H. Nodes B thru G are useful but clutter up my timeline in terms of meaningful history. Node D might be the renaming of a variable for example. Nice to have as a delta on the timeline but just noise in terms of history. I'm hoping this hiding feature will make it easy to hide B thru G. It would be very nice also if bisect could be told to ignore hidden nodes. On Dec 3, 2013 2:03 AM, "Jan Nijtmans" <[email protected]> wrote:
> 2013/12/3 Andy Bradford > <[email protected]>: > > But if someone simply wants to hide a branch of development from the > > timeline, it would be a mistake to close the branch. Should we assume > > that a hidden branch is also one that is considered to be a ``mistake?'' > > My initial idea was that when making a "mistake", 3 things should be done: > - Move the commit (or multiple commits) to branch "mistake" > - Close the branch. > - Hide the branch. > Hiding should only allowed for closed branches. But this turns out to be > difficult to implement: Checking whether the branch is closed must follow > the succeeding commits, and then check the "closed" tag on the leaf. > Much easier was to combine the last two steps. If you don't want the > branch being closed (although I cannot imagine a useful use-case > for that), you can always re-open it. > > > Given that there is also alread a checkbox for ``Mark this leaf as > > closed...'' should it be forced in the event that something is marked as > > hidden? The user has the option there to check if they want and it may > > be less of a surprise factor since they will have to explicitly check it > > to make it closed. > There's a difference: The ``Mark this leaf as closed...'' checkbox closes > the current node only, not any succeeding nodes. This makes sense, > as any node having successors on the same branch is already closed > implicitly. Hiding a branch should set a propagating "hidden" tag on the > current node and the "closed" tag on the leaf node. But setting a > propagating "closed" tag on the current node has exactly the same > effect: it automatically propagates to the leaf we otherwise > would need to search for. It makes the implementation and the > use-case much simpler, and does exactly what I want to happen. > > If both the ``Mark this leaf as closed...'' and the "Hide..." checkbox > are selected, the second has precedence: You cannot put a > propagating "hidden" tag and a normal "hidden" tag on the same > node. But it's not an error: both checkboxes have the same > effect. Some javascript which selects the ''Mark.." checkbox > when the "Hide.." checkbox is selected would be super! > > 2013/12/3 Andy Bradford > <[email protected]>: > > I did notice that there appears to be an unused variable: > > > > > http://www.fossil-scm.org/index.html/artifact/a366fc950d92e1b7d063855450561128adb149bc?ln=1758 > > > > It gets set on line 1758, but then never used; consequently it appears > > that the -u|--unhide option in the commandline timeline doesn't work. > > I didn't manage to get the SQL right for the commandline timeline, > yet. That's all. > > Thanks! > Jan Nijtmans > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
