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

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

Re: [fossil-users] Git just got shallow and sparse clones

Just‎ to contribute my 2 cents to this discussion, for our workflow I'd find sparse clones much more useful than shallow ones, although I can see how deep history can slow initial clone, and that past certain point is rarely useful. It's not our problem - but we have thousands of separate

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

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

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

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,

Re: [fossil-users] Git just got shallow and sparse clones

On Feb 4, 2017, at 6:07 AM, Konstantin Khomoutov wrote: > > commit 016e6ccbe03438454777e43dd73d67844296a3fd > Author: Johannes Schindelin > Date: Mon Oct 30 20:09:29 2006 +0100 > >allow cloning a repository “shallowly" That’s

Re: [fossil-users] Git just got shallow and sparse clones

On Feb 6, 2017, at 4:49 PM, Warren Young wrote: > >> allow cloning a repository “shallowly" > > That’s not what I mean by “shallow,” since according to the docs,[1] Oh, I see the --no-single-branch bit now. Sigh, another confusing Git default. Even so, it still doesn’t

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

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

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

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

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 if you include a --branch argument on "fossil

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

+1 This would also guard against unplanned/accidental use of same branch name in a repo with tens of older inactive branches one cannot possible remember at all times. -Original Message- From: Richard Hipp Sent: Monday, February 06, 2017 6:18 PM To: Fossil SCM user's discussion