Thus said Jan Nijtmans on Wed, 04 Dec 2013 10:49:44 +0100:
> I'm not sure if some more protection is needed: Any change done
> through this page can just as easily been undone through succeeding
> edits. For example "Branch closure" could be hidden if the branch is
> "trunk", the "new
2013/12/4 Andy Bradford :
> Also, it would be nice if from the trunk, it was possible to mark
> something as hidden if there is also a branch tag being added. At the
> moment, if I have something that is in trunk that I want to move to the
> ``mistake'' branch and hide, I have to first
Thus said Themba Fletcher on Tue, 03 Dec 2013 13:38:50 -0800:
> I found yesterday that I could trigger a strange visual glitch with
> the following sequence of actions (and confirmed again just now):
I too have triggered strange visual glitches, some of which I have not
yet determined how to
Jan,
Thanks for your work on this -- it's a welcome addition.
I found yesterday that I could trigger a strange visual glitch with the
following sequence of actions (and confirmed again just now):
This is fossil version 1.28 [1a453093bb] 2013-12-03 15:42:53 UTC
$ fossil init test.fossil
$ fossil
2013/12/3 Andy Bradford :
> For the usage you present it might make more sense if the hidden
> tag were not propagating. It is still achievable with the current
> implementation by simply adding a cancelling tag at the point where you
> don't want it. The only snag is that curre
Thus said Matt Welland on Tue, 03 Dec 2013 06:11:50 -0700:
> 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.
Yes, it does seem that the primary usage is for mi
Thus said Jan Nijtmans on Tue, 03 Dec 2013 10:03:08 +0100:
> There's a difference: The ``Mark this leaf as closed...'' checkbox
> closes the current node only, not any succeeding nodes.
Good point, I had forgotten that this option only applied to leaves as
the option implies. :-) Forget I e
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
i
2013/12/3 Andy Bradford
:
> 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
Thus said Jan Nijtmans on Mon, 02 Dec 2013 09:52:01 +0100:
> Any more feedback? If not I would like to merge this to trunk.
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 li
Thus said Jan Nijtmans on Mon, 02 Dec 2013 09:52:01 +0100:
> The "Unhide" button is implemented now (and a corresponding "unhide"
> JSON option too):
I just now added an option to control the default setting for ``unhide''
which also adds a Hide button when necessary. I'm not sure if we have
Thus said Jan Nijtmans on Mon, 02 Dec 2013 09:52:01 +0100:
> This feature is mainly intended for the "mistake" branch, and if I
> make a mistaken commit then the succeeding commits on the same branch
> are surely a mistake too!
But if someone simply wants to hide a branch of development
2013/11/26 Andy Bradford :
> I brought it up merely because I was able to cause it to happen with
> Jan's current implementation and wondered what should be the correct way
> to display a hidden tag that is non-propagating. It seems fairly
> straightfoward with a propagating hidden tag:
Thus said Ron Wilson on Tue, 26 Nov 2013 15:17:31 -0500:
> At the same time, I find it strange to hide commits whose content is
> still being used (unless "c" is just a reversion of those changes, but
> then I'd just commit against "a", leaving "b" as an abandoned
> fork/branch)
I too
b is not a fork, nor is it abandoned. think of it as math. The delta a-c is
equal to the sum of a-b and b-c. You can hide b and think in terms of a-c
just fine. The only complication is if other branches derive from b. but
that is up to the user to think carefully and mean what they say when they
h
On Tue, Nov 26, 2013 at 2:42 PM, Andy Bradford wrote:
> Thus said Matt Welland on Tue, 26 Nov 2013 12:01:30 -0700:
>
> > Do you now have:
> >
> > -> a -> c ->
> >
> > OR
> >
> > -> a c ->
>
> What about:
>
> -> a => c ->
>
> Where => is a new line style that indicates a hidden line of comm
Thus said Matt Welland on Tue, 26 Nov 2013 12:01:30 -0700:
> Do you now have:
>
> -> a -> c ->
>
> OR
>
> -> a c ->
What about:
-> a => c ->
Where => is a new line style that indicates a hidden line of commits
between a and c?
Andy
--
TAI64 timestamp: 40005294f9ae
___
Hiding clutter is hugely important in my opinion. If something is marked as
irrelevant then hide it regardless of how the final timeline looks. However
an obvious button to toggle show-all on the timeline would be equally
important.
I see the intent as enabling a view of the important and relevant
Thus said Jan Nijtmans on Tue, 26 Nov 2013 12:50:52 +0100:
> At this moment, only single nodes can be hidden, that's intended. I
> see no problems making it propagating, it would make it easier to hide
> big parts without anyone noticing. I'm not sure we want to encourage
> that.
Tough choic
On Mon, Nov 25, 2013 at 11:11:00PM -0700, Andy Bradford wrote:
> Thus said Jan Nijtmans on Mon, 25 Nov 2013 17:08:07 +0100:
>
> > Any objections to this change? At least it's not dangerous at all:
> > It's just as easy to "unhide" items than to hide them, just by
> > removing the "hidd
2013/11/26 Andy Bradford
:
> First, if I hide a check-in and rename the branch to mistake, when I
> view the mistake branch using /timeline?r=mistake those items do not
> show up; of course this is certainly working as it should, but because
> there is no way to reveal them, I am none the
Thus said Jan Nijtmans on Mon, 25 Nov 2013 17:08:07 +0100:
> Any objections to this change? At least it's not dangerous at all:
> It's just as easy to "unhide" items than to hide them, just by
> removing the "hidden" tag later.
Just some quick observations and questions.
First, if I
2013/11/25 Andy Bradford :
> I moved the code to mistake.
A feature I wanted for some time - and finally got around
implementing - is the possibility to hide (my) items from
the timeline. So whenever I make a mistake, I can move
it to the "mistake" branch and then hide it. It will still be
synch
23 matches
Mail list logo
