Re: [fossil-users] Bug in "fossil branch new"

[Martin S. Weber]

On 2017-02-06 23:17:00, Andy Bradford wrote:
> (...)
> Because it doesn't  matter what the name  of the branch is.  
> (continues to show examples where Andy, as the human, uses the branch-name to
> identify the branch)

thanks for proving my point.

Regards,
-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug in "fossil branch new"

[Andy Bradford]

Thus said "Martin S. Weber" on Tue, 07 Feb 2017 11:07:55 +0100:

> thanks for proving my point.

You're welcome. I  never said branch names don't identify  a branch, nor
that they  are meaningless.  I said  that when  you use  ``fossil branch
new'' that  it doesn't imply that  the following commit will  be on that
branch.

And given the following:

> This could  be mitigated,  by keeping  the same  design, with  the CLI
> actually outputting  an identity  of the  branch that  can be  used to
> select that specific branch.  If the name is but a  tag, do output the
> actual identity.  Problem then becomes one  of the user-unfriendliness
> of entering hashes for symbolic names (why have symbolic names if they
> are worthless?).

Does not  Fossil allow  the use  of names for  most operations  and will
attempt to  resolve them  in a deterministic  fashion? Who  claimed that
they are worthless?

If I run ``fossil branch new'' it  creates a new branch according to the
BASIS that I gave it. It also outputs the artifact ID of the commit that
this tag was assigned  to (remember, a branch name is merely  a tag on a
commit, so one cannot have a tag without a commit).

I  agree,  however,  that  ``fossil  branch  new''  could  provide  more
information as to the state of the repository, and so:

http://www.fossil-scm.org/index.html/info/cbde195a118e231f

Which produces output like:

$ ./fossil branch new test 3f9a077a8d85d6bf5690f93ea561d6ee10c46024
New branch: c63492a121dd8af63e05924dfa4563a79fbae367
uuid: 3f9a077a8d85d6bf5690f93ea561d6ee10c46024 2017-02-07 14:57:22 UTC
child:c63492a121dd8af63e05924dfa4563a79fbae367 2017-02-07 14:57:56 UTC
tags: trunk
comment:  initial empty check-in (user: amb)

Maybe this isn't even sufficient, but I do believe it's an improvement.

Andy
-- 
TAI64 timestamp: 40005899e0dc


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug in "fossil branch new"

[john lunzer]

I think there is merit to this thought but I'd be careful. There is a risk
of drowning important information which would do the opposite of helping
"newbies".

On Tue, Feb 7, 2017 at 10:24 AM, Richard Hipp  wrote:

> On 2/7/17, Andy Bradford  wrote:
> >
> > Maybe this isn't even sufficient, but I do believe it's an improvement.
> >
>
> Here is a crazy, crazy thought:
>
> Suppose we put lots and lots of extra text on many of the Fossil
> commands, explaining
> what just happened and the current repository state, after every
> command.  Then provide a command like:
>
>  fossil set newbie-hints off --global
>
> That will turn off all the extra verbiage after users get comfortable
> with the system.
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug in "fossil branch new"

[Richard Hipp]

On 2/7/17, john lunzer  wrote:
> There is a risk
> of drowning important information which would do the opposite of helping
> "newbies".

Agreed.  Finding the right balance is tricky.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug in "fossil branch new"

[john lunzer]

If you're avoiding "fossil branch new" because it doesn't automatically
switch and you got confused about the behavior doesn't that help show that
it makes sense to automatically switch by default?

I think the most "logical" design would be for the behavior of both branch
creation methods to match as closely as possible. In this case both methods
should switch the branch just created and tell the user it switched.

If you want to retain previous behavior you can add a "--no-switch" flag
which will keep you on your current branch. This way if somebody's legacy
script were to break it would be a simple matter of adding the switch,
rather than having to combine other commands to get the legacy behavior.

On Tue, Feb 7, 2017 at 1:19 AM, Andy Bradford 
wrote:

> Thus said Richard Hipp on Mon, 06 Feb 2017 14:49:30 -0500:
>
> > Rather than break legacy scripts,  perhaps a warning message that says
> > "the new  branch has been  created but you  are not currently  on that
> > branch - type "fossil update BRANCHNAME" to go there" or similar?
>
> I  think a  warning  should suffice.  While I  have,  on occasion,  also
> forgotten  that ``fossil  branch new''  doesn't automatically  switch, I
> have gotten into  the habit of using ``fossil  commit --branch'' because
> it seems more natural, and doesn't  create an extra artifact that exists
> solely to create a branch (though I can understand why some would prefer
> this method).
>
> Andy
> --
> TAI64 timestamp: 400058996706
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug in "fossil branch new"

[Martin S. Weber]

On 2017-02-07 07:59:03, Andy Bradford wrote:
> Thus said "Martin S. Weber" on Tue, 07 Feb 2017 11:07:55 +0100:
> 
> > thanks for proving my point.
> 
> You're welcome. I  never said branch names don't identify  a branch, nor
> that they  are meaningless.  

drh said branch names don't identify a branch, not you. If names did identify
branches, there would be no way to have two separate branches of the same 
name, as the name would uniquely identify a branch. It doesn't, though.

> I said  that when  you use  ``fossil branch
> new'' that  it doesn't imply that  the following commit will  be on that
> branch.

a fossil update following the branch new would be more user-friendly indeed,
at least IMHO.

My point is, what is the rationale for names not identifying branches
uniquely. Why can I multiple branches off of several basis that have the
same name? See my previous email with the fossil command log output how
even fossil assumes the samely named branches are the same (by outputting
one leaf as "current" and not the other, whereas, if these are indeed
separate branches, both leaves of the same-named branch name need to
be "current").

> 
> And given the following:
> 
> > This could  be mitigated,  by keeping  the same  design, with  the CLI
> > actually outputting  an identity  of the  branch that  can be  used to
> > select that specific branch.  If the name is but a  tag, do output the
> > actual identity.  Problem then becomes one  of the user-unfriendliness
> > of entering hashes for symbolic names (why have symbolic names if they
> > are worthless?).
> 
> Does not  Fossil allow  the use  of names for  most operations  and will
> attempt to  resolve them  in a deterministic  fashion? Who  claimed that
> they are worthless?

Well, worthless in its ultimate ratio in its current state (aka playing
devil's advocate). Deterministically picking the wrong thing doesn't 
help. See the email with the fossil output. If I can only pick the "other"
dev branch by its hash, then the name of that "other" dev branch has become
worthless, as it will not resolve to the older one.

Regards,
-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug in "fossil branch new"

[Richard Hipp]

On 2/7/17, Andy Bradford  wrote:
>
> Maybe this isn't even sufficient, but I do believe it's an improvement.
>

Here is a crazy, crazy thought:

Suppose we put lots and lots of extra text on many of the Fossil
commands, explaining
what just happened and the current repository state, after every
command.  Then provide a command like:

 fossil set newbie-hints off --global

That will turn off all the extra verbiage after users get comfortable
with the system.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug in "fossil branch new"

[Tony Papadimitriou]

Hmm, but isn't it usually the newbies that do NOT read any documentation? :)

However, if this gets implemented here's a somewhat crazier thought to make 
it ever better for the general public:


fossil set newbie-mode = 

where  is blank indicating "I don't know what I'm supposed to be doing 
here" so fossil will print the whole manual for each command together with 
relevant Wikipedia links as to what an SCM is good for along with real-life 
examples of success stories,
or  is 'youtube' where all help is made of video clips of the 
corresponding concepts or command actions,
or  is 'gui' for the command-line impaired where the command-line 
interface will be completely disabled and everything will be possible from 
the GUI,
or  is 'git' indicating I come from the git world and I refuse to 
learn fossil so I want all commands to show me the git equivalent way,  or 
even better, fossil should accept git commands directly,
or  is 'expert' indicating that all help should be single-liners 
referring to all commands and options with their minimum required text and 
describing all actions with just mathematical symbols,
or  is 'false' for keeping it the way it is now (merely for backwards 
compatibility as I'm sure the majority will want to switch to one of the new 
fancier modes),

... space reserved for additional brainstorming ...

(Now, I hope nobody took this seriously.)

-Original Message- 
From: Richard Hipp


Here is a crazy, crazy thought:

Suppose we put lots and lots of extra text on many of the Fossil
commands, explaining
what just happened and the current repository state, after every
command.  Then provide a command like:

fossil set newbie-hints off --global

That will turn off all the extra verbiage after users get comfortable
with the system.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug in "fossil branch new"

[Andy Bradford]

Thus said Richard Hipp on Tue, 07 Feb 2017 10:24:46 -0500:

> Suppose we  put lots  and lots  of extra  text on  many of  the Fossil
> commands,  explaining what  just happened  and the  current repository
> state, after every command. Then provide a command like:
> 
>  fossil set newbie-hints off --global

No thanks. :-)

As it turns out, it looks like there may have been some code at one time
that output a warning:

https://www.fossil-scm.org/index.html/artifact?ln=165,174=efbe1da922f3dc43

Personally I find the show_common_info  more interesting to look at than
a warning, but I'm also fine leaving ``fossil branch new'' as-is.

As I  said in another  email, ``fossil  branch new'' behavior  should be
familiar to anyone  who uses ``git branch ''  which also does
not even output a commit hash, or give other details.

Andy
--
TAI64 timestamp: 4000589a1f1d
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug in "fossil branch new"

[Andy Bradford]

Thus said "Martin S. Weber" on Tue, 07 Feb 2017 17:04:00 +0100:

> Well,  worthless in  its  ultimate  ratio in  its  current state  (aka
> playing devil's  advocate). Deterministically picking the  wrong thing
> doesn't help. See the email with the fossil output. If I can only pick
> the "other" dev branch by its hash,  then the name of that "other" dev
> branch has become worthless, as it will not resolve to the older one.

I don't think it's entirely worthless, anymore than having two people in
the same room at the same time both having the same name. To address one
or the other, some other indication must be made; for example, one might
move  closer to  the one  that is  intended to  be addressed,  or use  a
nickname, or some other thing.

If I have 2  branches by the same name, I move closer  to the one I want
using the UUID, then further  commits at this point *will* automatically
be applied to that particular instance  of the same branch name, and not
the  most  recent branch  by  that  name. By  that  measure,  it is  not
worthless  because when  I finally  spin  up Fossil  UI to  look at  the
history I  will see the  progress of the  individual branches just  as I
expect.

It's interesting to  note that when Fossil was  first publicly released,
there was no  concept of a ``branch'' but only  forks. Notice that there
are 2 long-term trunks and a number of temporary 3rd trunks:

https://www.fossil-scm.org/index.html/timeline?unhide=on=25=all==exact=fff234b77cc774ca

How did one resolve the  difference between the development on different
forks of trunk? UUID.

Thanks,

Andy
-- 
TAI64 timestamp: 4000589a3b24


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug in "fossil branch new"

[Andy Bradford]

Thus said john lunzer on Tue, 07 Feb 2017 10:39:49 -0500:

> If   you're  avoiding   "fossil   branch  new"   because  it   doesn't
> automatically switch and  you got confused about  the behavior doesn't
> that help show that it makes sense to automatically switch by default?

Not that  this supports Fossil's  choice to  not switch by  default, but
neither does ``git branch newbranch'' automatically switch branches. One
must  follow ``git  branch newbranch''  with ``git  checkout newbranch''
before the following commit will land on the new branch.

Andy
--
TAI64 timestamp: 4000589a1dbc
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users