Thus said john lunzer on Sun, 05 Feb 2017 13:06:04 -0500:
> Here is the test sequence:
>
> cd fossils
> fossil new testrepo.fossil
> mkdir ../testrepo
> cd ../testrepo
> fossil open ../fossils/testrepo.fossil
> fossil branch new myfirstbranch trunk
> fossil commit --allow-empty --branch myfirstbr
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
her
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" d
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
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 suppo
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
foss
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 d
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 br
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
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
com
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
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
___
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?
Come to think of it, wha
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 sho
Thus said "Martin S. Weber" on Mon, 06 Feb 2017 18:10:15 +0100:
> Well, given fossil's CLI requires BRANCH-NAME as input, how can the
> following commit not go to the same branch?
Because it doesn't matter what the name of the branch is. It's just a
tag. What is really critical is the BASIS
On Feb 6, 2017, at 9:18 AM, Richard Hipp wrote:
>
> Does anybody else having any feelings one way or another about this?
I’m not sure I’ve run into *quite* the same case, but a related one I did run
into recently was trying to migrate from a “release” tag (as Fossil itself
uses) to a “release”
ssion
Subject: Re: [fossil-users] Bug in "fossil branch new"
On 2/6/17, Richard Hipp wrote:
That is correct, and it is by design. Fossil allows any number of
branches to share the same name.
On second thought, perhaps it would be worthwhile to enhance Fossil so
that it issued a warning
A warning would minimally address the issue but there would still be a
behavioral inconsistency with "fossil commit --branch" which does
automatically move you into the new branch. This inconsistency opens the
door to confusion.
That said, I think both "fossil branch new" and "fossil commit --bran
On 6 February 2017 at 11:49, Richard Hipp wrote:
> 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'd prefer a warning over a assumed aut
On 2/6/17, john lunzer wrote:
> One more thing I think is necessary to mostly eliminate the confusion.
> Currently "fossil branch new BRANCHNAME" is not followed by an automatic
> "fossil update BRANCHNAME". This I think will be surprising when the user
> goes to do their first "fossil commit" thi
On 2/6/17, john lunzer wrote:
>
> How is this not a bug?
A "bug" means the software gets the wrong answer.
That the software does not match the mental model of new users is not
a bug. it is (perhaps) a usability concern that can be addressed, but
that is different from a bug.
Perhaps your conc
One more thing I think is necessary to mostly eliminate the confusion.
Currently "fossil branch new BRANCHNAME" is not followed by an automatic
"fossil update BRANCHNAME". This I think will be surprising when the user
goes to do their first "fossil commit" thinking they are committing to the
branch
Haha, please disregard my previous message. You posted while I was still
typing the other. Your action will mostly take care of the issue. Thank you
for considering my situation.
If I may ask though, if autosync is off how would the situation of two
developers creating a branch by the same name an
On Mon, Feb 6, 2017 at 11:13 AM, Richard Hipp wrote:
>
> >
> > After the second "fossil commit --branch myfirstbranch" no new branch is
> > created, commited to the same branch as the after the first "fossil
> commit
> > --branch myfirstbranch"
>
> Actually, it did create a new branch off of the
On 2/6/17, bch wrote:
> I haven't ever run into this issue, but what you're wondering about sounds
> reasonable on the surface. "Principle of least surprise", and all...
>
The trunk version of Fossil will now only permit the --branch option
on a "fossil commit" if the named branch either does not
On 2017-02-06 11:13:46, Richard Hipp wrote:
> (...)
> Probably you are coming from a different DVCS that requires branches
> to be created in advance of the commit and that also requires branch
> names to be unique. Fossil has neither of these constraints, and so
> it operates a little differently
I haven't ever run into this issue, but what you're wondering about sounds
reasonable on the surface. "Principle of least surprise", and all...
-bch
On Feb 6, 2017 08:18, "Richard Hipp" wrote:
> On 2/6/17, Richard Hipp wrote:
> >
> > That is correct, and it is by design. Fossil allows any num
On 2/6/17, Richard Hipp wrote:
>
> That is correct, and it is by design. Fossil allows any number of
> branches to share the same name.
On second thought, perhaps it would be worthwhile to enhance Fossil so
that it issued a warning if you include a --branch argument on "fossil
commit" with the s
On 2/5/17, john lunzer wrote:
> Here is the test sequence:
>
> cd fossils
> fossil new testrepo.fossil
> mkdir ../testrepo
> cd ../testrepo
> fossil open ../fossils/testrepo.fossil
> fossil branch new myfirstbranch trunk
> fossil commit --allow-empty --branch myfirstbranch -m "A new branch"
> fos
Here is the test sequence:
cd fossils
fossil new testrepo.fossil
mkdir ../testrepo
cd ../testrepo
fossil open ../fossils/testrepo.fossil
fossil branch new myfirstbranch trunk
fossil commit --allow-empty --branch myfirstbranch -m "A new branch"
fossil commit --allow-empty --branch myfirstbranch -
30 matches
Mail list logo