[fossil-users] Why do people create branches as a separate step? Was: Unable to sign manifest

[Richard Hipp]

fossil branch new Test 5947928ba****

Change the subject: Please help me to understand why people want to create
a new branch before adding changes to that branch, rather than just waiting
until they check-in their edits? I'm not being sarcastic or critical here.
A lot of people do this and I sincerely want to understand the motivation.

The way I've *always* done things is:

(1) ... edit files
(2) fossil commit -branch new-branch

But I see many people want to do a 4-step process:

(1) fossil branch new new-branch
(2) fossil update new-branch
(3) ... edit files
(4) fossil commit

That seems like so much more trouble. What am I missing? Is it that people
are unaware that they can make edits that are destined to go into a branch
before that branch actually exists? Do I need to improve on the
documentation? Or does creating the branch first, before making file edits,
just fit most peoples mental model better? Are there some advantages to
creating branches in advance that I am missing?

Part of the motivation for this question is that, because I never use
"fossil branch new" myself, there tend to be more bugs in that command than
in the other commands that I use daily. If there is a good reason to do
"fossil branch new" then maybe I'll start using it myself and those bugs
will get fixed sooner. Or if not, maybe I'll deprecate "fossil branch new"
- or at least print a warning and ask for confirmation: "Creating branches
ahead of check-ins is unnecessary. Are you sure you want to do this? (y/N)"

Please explain. Thanks!

[Gour-Gadadhara Dasa]

On Tue, 9 Aug 2011 10:58:02 -0400

Post by Richard Hipp
Please help me to understand why people want to
create a new branch before adding changes to that branch, rather than
just waiting until they check-in their edits? I'm not being
sarcastic or critical here. A lot of people do this and I sincerely
want to understand the motivation.

Maybe the way how other DVCS work?

Which DVCS can create branch along with the commit?


Sincerely,
Gour

[Joshua Paine]

Post by Gour-Gadadhara Dasa
Maybe the way how other DVCS work?
Which DVCS can create branch along with the commit?

I was thinking it was possible and I had done it in git, but I don't
remember how or see it in the documentation, so I think I was mistaken.

[Konstantin Khomoutov]

On Tue, 9 Aug 2011 17:04:04 +0200

Post by Gour-Gadadhara Dasa

Post by Richard Hipp
Please help me to understand why people want to
create a new branch before adding changes to that branch, rather
than just waiting until they check-in their edits? I'm not being
sarcastic or critical here. A lot of people do this and I sincerely
want to understand the motivation.

Maybe the way how other DVCS work?
Which DVCS can create branch along with the commit?

Basically any, I presume, which does not overwrite (reset or whatever
you call it) local modifications when updating the work tree (work
directory) to the new branch's tip.
Hence from my personal experience I can say that Git and Subversion
allow to do this.

[Ambrose Bonnaire-Sergeant]

Personally, this is a habit I bring from git, mainly because I'm not aware
of any other way to doing things.

I was not aware of fossil commit -branch new-branch, seems like a much
better alternative.

Half the time I start hacking on something, then "oh, darn I should have
started a branch before I started". This seems much superior.

Thanks,
Ambrose

[Lluís Batlle i Rossell]

Post by Ambrose Bonnaire-Sergeant
Personally, this is a habit I bring from git, mainly because I'm not aware
of any other way to doing things.
I was not aware of fossil commit -branch new-branch, seems like a much
better alternative.
Half the time I start hacking on something, then "oh, darn I should have
started a branch before I started". This seems much superior.

You can even set the branch *after* you commit, through the web ui.

[Joshua Paine]

Post by Richard Hipp
Change the subject: Please help me to understand why people want to
create a new branch before adding changes to that branch, rather than
just waiting until they check-in their edits?

In SVN (and possibly others), you have to create the branch first. In
Git I still try to make the branch first, because I don't know how to
move a commit to a new branch if I forget to add the new branch argument
when I commit. The GUI tools I've used for SVN and Git didn't make it
easy to put a commit on a new branch.

In fossil I often just work and worry about branches later, sometimes
several commits later, because I know it's really easy to change it. In
those cases, I've usually started working on something and realized part
way in that I had better branch for this--a totally stress-free
realization with fossil. But sometimes I still make the branch first,
because sometimes my thought process begins with "Now I'm going to start
on New Feature X," and since I've just decided that, I may as well make
some manifestation of my intention.

I like that both ways are supported, along with the ability to make new
branches after the fact.

[t***@compumation.com]

So, how do you move commits in the trunk to a new branch after the fact.

Thanks,
Tony Perovic

-----Original Message-----
From: fossil-users-***@lists.fossil-scm.org [mailto:fossil-users-***@lists.fossil-scm.org] On Behalf Of Joshua Paine
Sent: Tuesday, August 09, 2011 10:10 AM
To: fossil-***@lists.fossil-scm.org
Subject: Re: [fossil-users] Why do people create branches as a separate step? Was: Unable to sign manifest

Post by Richard Hipp
Change the subject: Please help me to understand why people want to
create a new branch before adding changes to that branch, rather than
just waiting until they check-in their edits?

In SVN (and possibly others), you have to create the branch first. In Git I still try to make the branch first, because I don't know how to move a commit to a new branch if I forget to add the new branch argument when I commit. The GUI tools I've used for SVN and Git didn't make it easy to put a commit on a new branch.

In fossil I often just work and worry about branches later, sometimes several commits later, because I know it's really easy to change it. In those cases, I've usually started working on something and realized part way in that I had better branch for this--a totally stress-free realization with fossil. But sometimes I still make the branch first, because sometimes my thought process begins with "Now I'm going to start on New Feature X," and since I've just decided that, I may as well make some manifestation of my intention.

I like that both ways are supported, along with the ability to make new branches after the fact.

--
Joshua Paine
LetterBlock: Web Applications Built With Joy http://letterblock.com/
301-576-1920

[Lluís Batlle i Rossell]

Post by t***@compumation.com
So, how do you move commits in the trunk to a new branch after the fact.

Open the UI, click the checkin, then edit... and check the part about "starts a new
branch".

Regards,
Lluís.

Post by t***@compumation.com
-----Original Message-----
Sent: Tuesday, August 09, 2011 10:10 AM
Subject: Re: [fossil-users] Why do people create branches as a separate step? Was: Unable to sign manifest

Post by Richard Hipp
Change the subject: Please help me to understand why people want to
create a new branch before adding changes to that branch, rather than
just waiting until they check-in their edits?

In SVN (and possibly others), you have to create the branch first. In Git I still try to make the branch first, because I don't know how to move a commit to a new branch if I forget to add the new branch argument when I commit. The GUI tools I've used for SVN and Git didn't make it easy to put a commit on a new branch.
In fossil I often just work and worry about branches later, sometimes several commits later, because I know it's really easy to change it. In those cases, I've usually started working on something and realized part way in that I had better branch for this--a totally stress-free realization with fossil. But sometimes I still make the branch first, because sometimes my thought process begins with "Now I'm going to start on New Feature X," and since I've just decided that, I may as well make some manifestation of my intention.
I like that both ways are supported, along with the ability to make new branches after the fact.
--
Joshua Paine
LetterBlock: Web Applications Built With Joy http://letterblock.com/
301-576-1920
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Brian Cottingham]

Is there a way to do in from the command line?

Post by Lluís Batlle i Rossell

Post by t***@compumation.com
So, how do you move commits in the trunk to a new branch after the fact.

Open the UI, click the checkin, then edit... and check the part about "starts a new
branch".
Regards,
Lluís.

Post by t***@compumation.com
-----Original Message-----
Sent: Tuesday, August 09, 2011 10:10 AM
Subject: Re: [fossil-users] Why do people create branches as a separate

step? Was: Unable to sign manifest

Post by t***@compumation.com

Post by Richard Hipp
Change the subject: Please help me to understand why people want to
create a new branch before adding changes to that branch, rather than
just waiting until they check-in their edits?

In SVN (and possibly others), you have to create the branch first. In Git

I still try to make the branch first, because I don't know how to move a
commit to a new branch if I forget to add the new branch argument when I
commit. The GUI tools I've used for SVN and Git didn't make it easy to put a
commit on a new branch.

Post by t***@compumation.com
In fossil I often just work and worry about branches later, sometimes

several commits later, because I know it's really easy to change it. In
those cases, I've usually started working on something and realized part way
in that I had better branch for this--a totally stress-free realization with
fossil. But sometimes I still make the branch first, because sometimes my
thought process begins with "Now I'm going to start on New Feature X," and
since I've just decided that, I may as well make some manifestation of my
intention.

Post by t***@compumation.com
I like that both ways are supported, along with the ability to make new

branches after the fact.

Post by t***@compumation.com
--
Joshua Paine
LetterBlock: Web Applications Built With Joy http://letterblock.com/
301-576-1920
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Lluís Batlle i Rossell]

Post by Brian Cottingham
Is there a way to do in from the command line?

There is not much of any commit editing in the command line, for what I know.

But at commit time you have '-b'. So using the ui for those corner cases is not
a big trouble for me at least.

Post by Brian Cottingham

Post by Lluís Batlle i Rossell

Post by t***@compumation.com
So, how do you move commits in the trunk to a new branch after the fact.

Open the UI, click the checkin, then edit... and check the part about "starts a new
branch".
Regards,
Lluís.

Post by t***@compumation.com
-----Original Message-----
Sent: Tuesday, August 09, 2011 10:10 AM
Subject: Re: [fossil-users] Why do people create branches as a separate

step? Was: Unable to sign manifest

Post by t***@compumation.com

Post by Richard Hipp
Change the subject: Please help me to understand why people want to
create a new branch before adding changes to that branch, rather than
just waiting until they check-in their edits?

In SVN (and possibly others), you have to create the branch first. In Git

I still try to make the branch first, because I don't know how to move a
commit to a new branch if I forget to add the new branch argument when I
commit. The GUI tools I've used for SVN and Git didn't make it easy to put a
commit on a new branch.

Post by t***@compumation.com
In fossil I often just work and worry about branches later, sometimes

several commits later, because I know it's really easy to change it. In
those cases, I've usually started working on something and realized part way
in that I had better branch for this--a totally stress-free realization with
fossil. But sometimes I still make the branch first, because sometimes my
thought process begins with "Now I'm going to start on New Feature X," and
since I've just decided that, I may as well make some manifestation of my
intention.

Post by t***@compumation.com
I like that both ways are supported, along with the ability to make new

branches after the fact.

Post by t***@compumation.com
--
Joshua Paine
LetterBlock: Web Applications Built With Joy http://letterblock.com/
301-576-1920
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

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

[Matt Welland]

I often am planning a change or thinking ahead and will create the branch to
record my intentions before I've started coding. I do like the ability to
checkin changes to a branch but would generally not intentionally use it out
of the risk of forgetting that my changes are intended for a branch and then
checking them in to the current branch.

Note: It is annoying to me that "fossil branch new foo" won't simply branch
from the current node.

By the way, how does "update" differ from "co" in your step 2 below?

Post by Richard Hipp

fossil branch new Test 5947928ba****

Change the subject: Please help me to understand why people want to create
a new branch before adding changes to that branch, rather than just waiting
until they check-in their edits? I'm not being sarcastic or critical here.
A lot of people do this and I sincerely want to understand the motivation.
(1) ... edit files
(2) fossil commit -branch new-branch
(1) fossil branch new new-branch
(2) fossil update new-branch
(3) ... edit files
(4) fossil commit
That seems like so much more trouble. What am I missing? Is it that
people are unaware that they can make edits that are destined to go into a
branch before that branch actually exists? Do I need to improve on the
documentation? Or does creating the branch first, before making file edits,
just fit most peoples mental model better? Are there some advantages to
creating branches in advance that I am missing?
Part of the motivation for this question is that, because I never use
"fossil branch new" myself, there tend to be more bugs in that command than
in the other commands that I use daily. If there is a good reason to do
"fossil branch new" then maybe I'll start using it myself and those bugs
will get fixed sooner. Or if not, maybe I'll deprecate "fossil branch new"
- or at least print a warning and ask for confirmation: "Creating branches
ahead of check-ins is unnecessary. Are you sure you want to do this? (y/N)"
Please explain. Thanks!
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Joshua Paine]

Post by Matt Welland
Note: It is annoying to me that "fossil branch new foo" won't simply
branch from the current node.

+1

Post by Matt Welland
By the way, how does "update" differ from "co" in your step 2 below?

If you have no edited files, they have the same effect. But if you have
some edits that are not yet committed, co will fail unless called with
--force, in which case it will overwrite, whereas update will merge your
uncommitted changes in to the new branch's files as uncommitted changes.

[Lluís Batlle i Rossell]

Post by Joshua Paine

Post by Matt Welland
Note: It is annoying to me that "fossil branch new foo" won't simply
branch from the current node.

+1

Post by Matt Welland
By the way, how does "update" differ from "co" in your step 2 below?

If you have no edited files, they have the same effect. But if you have
some edits that are not yet committed, co will fail unless called with
--force, in which case it will overwrite, whereas update will merge your
uncommitted changes in to the new branch's files as uncommitted changes.

Moreover, 'co' is a much slower operation.

I think of 'update' as: bring my current working directory changes to the
check-in I say, considering what I have checked out.

And 'checkout' as: regardless of what I have in my working directory, bring
there the files for the named check-in.

[Konstantin Khomoutov]

On Tue, 9 Aug 2011 08:19:46 -0700

Post by Matt Welland
I often am planning a change or thinking ahead and will create the
branch to record my intentions before I've started coding. I do like
the ability to checkin changes to a branch but would generally not
intentionally use it out of the risk of forgetting that my changes
are intended for a branch and then checking them in to the current
branch.

I'd like to second all written above.
This is simply a mental model thing: "oh, these changes I've just made
should better be on the new branch" versus "now I want to implement a
new feature, so let's fork a new branch now and start coding *on it*".
Both are valid on different occasions.

Post by Matt Welland
Note: It is annoying to me that "fossil branch new foo" won't simply
branch from the current node.

Absolutely agreed.
I miss Git's `git checkout -b newbranch` encantation which stands for
fossil branch new newbranch
fossil update newbranch
in fossil, which is barely a pleasure to use.

By the way, could it be possible to implement such "I want to start a
new branch now" without recording of any new artifacts but instead by
just creating some record (in _FOSSIL_, presumably), that the user
recorded her intention for the next commit she'll make to start a new
branch? That would be more in a fossil's style of managing branches, I
feel.

[Mike Meyer]

On Tue, Aug 9, 2011 at 8:35 AM, Konstantin Khomoutov <

Post by Konstantin Khomoutov
On Tue, 9 Aug 2011 08:19:46 -0700

Post by Matt Welland
I often am planning a change or thinking ahead and will create the
branch to record my intentions before I've started coding. I do like
the ability to checkin changes to a branch but would generally not
intentionally use it out of the risk of forgetting that my changes
are intended for a branch and then checking them in to the current
branch.

I'd like to second all written above.
This is simply a mental model thing: "oh, these changes I've just made
should better be on the new branch" versus "now I want to implement a
new feature, so let's fork a new branch now and start coding *on it*".
Both are valid on different occasions.

Does any other VCS have a "commit to <branch>" ability? I know some will let
you create a branch and update to it while preserving changes, but that kind
of thing always feels like an "oops, I made the changes to the wrong source"
type of thing than something planned.

Post by Konstantin Khomoutov

Post by Matt Welland
Note: It is annoying to me that "fossil branch new foo" won't simply
branch from the current node.

Absolutely agreed.
I miss Git's `git checkout -b newbranch` encantation which stands for
fossil branch new newbranch
fossil update newbranch
in fossil, which is barely a pleasure to use.
By the way, could it be possible to implement such "I want to start a
new branch now" without recording of any new artifacts but instead by
just creating some record (in _FOSSIL_, presumably), that the user
recorded her intention for the next commit she'll make to start a new
branch? That would be more in a fossil's style of managing branches, I
feel.

This is they way mercurial does things. Creating a branch is a local change,
and only happens on the repository when you commit those. I'd like it as
well - some way of noting that the work in the current checkout is destined
for some branch other than the one it's checked out of before I start the
work.

<mike

[Stephan Beal]

Post by Richard Hipp
That seems like so much more trouble. What am I missing? Is it that
people are unaware that they can make edits that are destined to go into a
branch before that branch actually

In my experience it's that when i know i've reached a branch point i clean
up my trunk, get it comitted, create the branch, and continue work from
there. i don't "spontaneously trunk", though i'm sure many do.

Post by Richard Hipp
Part of the motivation for this question is that, because I never use
"fossil branch new" myself, there tend to be more bugs in that command than
in the other commands that I use daily. If there is a good reason to do
"fossil branch new" then maybe I'll start using it myself and those bugs
will get fixed sooner. Or if not, maybe I'll deprecate "fossil branch new"
- or at least print a warning and ask for confirmation: "Creating branches
ahead of check-ins is unnecessary. Are you sure you want to do this? (y/N)"

i would be really annoyed by such a question - it's a perfect example of
software trying to go too far in its assumptions.

Post by Richard Hipp
Please explain. Thanks!

It's simply a different way of doing it.

[Lluís Batlle i Rossell]

Post by Richard Hipp
Change the subject: Please help me to understand why people want to create
a new branch before adding changes to that branch, rather than just waiting
until they check-in their edits? I'm not being sarcastic or critical here.
A lot of people do this and I sincerely want to understand the motivation.
(1) ... edit files
(2) fossil commit -branch new-branch

We very early discovered the "-b" parameter to "commit", and that's what we use
since then, but at our very first use of fossil, we only found "branch new" to create
a branch.

So, "branch new" was what we found first. Maybe the documentation about "branch
new" could explain about why would someone want to use it, explaining the other
possibilities.

I would not mind "branch new" deprecated.

Thank yu,
Lluís.

[Lluís Batlle i Rossell]

Post by Richard Hipp
(1) fossil branch new new-branch

I forgot to add that I don't like this approach *also* because it does not let
me type teh message that will appear in the timeline. So even I wanted to
declare some intentions for the time record, I would not use this because I
can't type what will appear there.

But of course, having "-b", even having the writing feature I would not use it.

[Brian Cottingham]

I agree with the others, I usually start a branch as a part of the process
of working on some new feature. It just feels more organized than
remembering to decide what branch to use when I finally commit, or changing
the branch after the fact.

Post by Lluís Batlle i Rossell

Post by Richard Hipp
(1) fossil branch new new-branch

I forgot to add that I don't like this approach *also* because it does not let
me type teh message that will appear in the timeline. So even I wanted to
declare some intentions for the time record, I would not use this because I
can't type what will appear there.
But of course, having "-b", even having the writing feature I would not use it.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Ron Wilson]

    (1)  ... edit files
    (2)  fossil commit -branch new-branch
    (1)  fossil branch new new-branch
    (2)  fossil update new-branch
    (3)  ... edit files
    (4)  fossil commit
That seems like so much more trouble.  What am I missing?  Is it that people
are unaware that they can make edits that are destined to go into a branch
before that branch actually exists?  Do I need to improve on the
documentation?  Or does creating the branch first, before making file edits,
just fit most peoples mental model better?  Are there some advantages to
creating branches in advance that I am missing?

Besides how older VCSs have worked, many work places have a policy of
doing work on branches, then merging the changes, later. By creating
the branch first, there is no ambiguity of where new commits will go.

[Matt Welland]

Post by Richard Hipp

Post by Richard Hipp
(1) ... edit files
(2) fossil commit -branch new-branch
(1) fossil branch new new-branch
(2) fossil update new-branch
(3) ... edit files
(4) fossil commit
That seems like so much more trouble. What am I missing? Is it that

people

Post by Richard Hipp
are unaware that they can make edits that are destined to go into a

branch

Post by Richard Hipp
before that branch actually exists? Do I need to improve on the
documentation? Or does creating the branch first, before making file

edits,

Post by Richard Hipp
just fit most peoples mental model better? Are there some advantages to
creating branches in advance that I am missing?

Besides how older VCSs have worked, many work places have a policy of
doing work on branches, then merging the changes, later. By creating
the branch first, there is no ambiguity of where new commits will go.

This is a good point. For development at work we are setting up git to allow
creating branches and limit who can check in on those branches (using
gitolite). Pre-creating branches is a hard requirement.

**soapbox mode - feel free to stop reading :) **

The list of things that chip away at making a case for using fossil in
serious work (lots of geographically distributed developers with minimal
communication channels and a complex project that contains many disparate
components) is not long, but does seem unnecessarily limiting:

1. ignores stored in db, no hierarchy, not revision controlled, propagated
with sync?
- minor but really annoying
2. symlinks not able to be stored (Windows support policy issue)
- can route around this one
3. no hooks (Windows support policy issue)
- deal breaker
4. mindshare (changing for the better every day but impacted by the above 3)

anything else?

Training time and ramp up on fossil is 100x faster than git and the
ticketing, wiki and web is absolutely fantastic but ignore files, symlinks
and hooks are basic features available in almost(1) *every* competing scm
and IMHO crippling fossil because of limitations of Microsoft Windows seems
unnecessary to me.

(1) Symlinks are the arguable exception here but on windows creating a file
with the link contents seems a fair fallback.

Just a random and unsolicited $0.02 precipitated by the incredible pain of
having to train myself and others on git. Something I'm not even 100%
certain I can successfully do for our team :-)

[Ben Summers]

Post by Matt Welland
**soapbox mode - feel free to stop reading :) **
1. ignores stored in db, no hierarchy, not revision controlled, propagated with sync?
- minor but really annoying

I had huge problems with settings like ignore-glob, so I have a branch which implements "versionable" settings which are just versioned files in a .fossil-settings directory.

I've been using it for a couple of months. Build the ben-testing branch if you'd like a play. Type "fossil help settings" for instructions. Testing and feedback appreciated!

I'm hoping I can get the ben-testing branch merged at some point. It has a few more useful (to me) changes: SSL client certs, empty-dirs setting, list changes & extras relative to the current working directory.

Ben


--
http://bens.me.uk/

[t***@compumation.com]

Because the Chapter 4.4 in the Fossil Version Control / Users Guide Version 1.7 by Jim Schimpf does it that way.

From: fossil-users-***@lists.fossil-scm.org [mailto:fossil-users-***@lists.fossil-scm.org] On Behalf Of Richard Hipp
Sent: Tuesday, August 09, 2011 9:58 AM
To: fossil-***@lists.fossil-scm.org
Subject: [fossil-users] Why do people create branches as a separate step? Was: Unable to sign manifest

On Tue, Aug 9, 2011 at 10:28 AM, ***@compumation.com<mailto:***@compumation.com> <***@compumation.com<mailto:***@compumation.com>> wrote:

fossil branch new Test 5947928ba



Change the subject: Please help me to understand why people want to create a new branch before adding changes to that branch, rather than just waiting until they check-in their edits? I'm not being sarcastic or critical here. A lot of people do this and I sincerely want to understand the motivation.

The way I've *always* done things is:

(1) ... edit files
(2) fossil commit -branch new-branch

But I see many people want to do a 4-step process:

(1) fossil branch new new-branch
(2) fossil update new-branch
(3) ... edit files
(4) fossil commit

That seems like so much more trouble. What am I missing? Is it that people are unaware that they can make edits that are destined to go into a branch before that branch actually exists? Do I need to improve on the documentation? Or does creating the branch first, before making file edits, just fit most peoples mental model better? Are there some advantages to creating branches in advance that I am missing?

Part of the motivation for this question is that, because I never use "fossil branch new" myself, there tend to be more bugs in that command than in the other commands that I use daily. If there is a good reason to do "fossil branch new" then maybe I'll start using it myself and those bugs will get fixed sooner. Or if not, maybe I'll deprecate "fossil branch new" - or at least print a warning and ask for confirmation: "Creating branches ahead of check-ins is unnecessary. Are you sure you want to do this? (y/N)"

Please explain. Thanks!

--
D. Richard Hipp
***@sqlite.org<mailto:***@sqlite.org>

[Gé Weijers]

Change the subject:  Please help me to understand why people want to create a new branch before adding
changes to that branch, rather than just waiting until they check-in their edits?  I'm not being
sarcastic or critical here.  A lot of people do this and I sincerely want to understand the motivation. 

If you create the branch first you cannot forget later and commit to the
wrong branch. It avoids operator error later on. If you need to edit a
file and save your changes to a copy you may do the same:

- open the file
- use the 'save as' command to change the name
- edit for 30 minutes
- use the 'save' command.

If you could just tell fossil that you intend to commit to a new branch
from the current workspace/checkout creating that extra commit object
could be avoided without risking a commit to the wrong branch.

$ fossil open ~/repos/mrcoffee.fossil
$ fossil branch next espresso-feature
.... much later ....
$ fossil commit
Commit to new branch 'espresso-feature'? (y/N)

Gé

[Lluís Batlle i Rossell]

Post by Gé Weijers

Change the subject:  Please help me to understand why people want to create a new branch before adding
changes to that branch, rather than just waiting until they check-in their edits?  I'm not being
sarcastic or critical here.  A lot of people do this and I sincerely want to understand the motivation. 

If you create the branch first you cannot forget later and commit to
the wrong branch. It avoids operator error later on. If you need to
- open the file
- use the 'save as' command to change the name
- edit for 30 minutes
- use the 'save' command.
If you could just tell fossil that you intend to commit to a new
branch from the current workspace/checkout creating that extra
commit object could be avoided without risking a commit to the wrong
branch.

You can *later* change the branch, after commit, as we have talked in this
thread. And it's not about overwriting files, like your file save example.

[Gé Weijers]

Post by Lluís Batlle i Rossell

Post by Gé Weijers
If you could just tell fossil that you intend to commit to a new
branch from the current workspace/checkout creating that extra
commit object could be avoided without risking a commit to the wrong
branch.

You can *later* change the branch, after commit, as we have talked in this
thread. And it's not about overwriting files, like your file save example.

True, but if your commit is to the wrong branch you're now in a race with
other people. If someone performs an 'update' before you change the branch
name using the GUI and push the change to the main repository your bad
commit propagates. If you do that to, say, the fossil 'trunk' branch for
instance someone somewhere is going to end up with your half-finished
feature in their production build.....

Gé

[Richard Hipp]

Post by Gé Weijers
If you create the branch first you cannot forget later and commit to the
wrong branch.

I beg to differ! Just this past Friday, I did three separate commits to
SQLite that went into the wrong branch even though the correct branch
already existed. If you look at
http://www.sqlite.org/src/timeline?r=query-planner-tweaks the three
check-ins eb43422827, e93c248c84, and 7e914aa999 were mistakenly made to
"trunk" instead of to the "query-planner-tweaks" branch. I didn't notice
the error until I looked at the timeline. To fix the problem, I had to move
the three check-ins over to a fork of the query-planner-tweaks branch then
merge the two forks, resulting in the funky graph that you see.

The query-planner-tweaks branch already existed when I make my three
mistakes. But I still managed to commit to the wrong branch. So, clearly,
just having the correct branch available does not mean you will commit to
it.

Post by Gé Weijers
$ fossil branch next espresso-feature

That's an interesting feature request. I'll take it under consideration...

[Gé Weijers]

If you create the branch first you cannot forget later and commit to the wrong branch.

I beg to differ!  Just this past Friday, I did three separate commits to SQLite that went into the wrong
branch even though the correct branch already existed.  [...]

In fossil (and in most other SCMs) you certainly can. It would be
different if the simplest way of creating a branch and moving your
workspace over would be a single action. In git for instance branch
creation can be done by

$ git checkout -b <branchname> -m

which creates the branch (locally) and moves any uncommitted changes over
in one go. Because git does not need to create a commit object to create a
branch the end result is similar to using

$ fossil commit --branch <branchname>

i.e. you do not end up with a commit that is essentially a copy of another
one.

BTW: the 'fossil branch next' idea is not original in retrospect.
Mercurial's 'hg branch' command works this way. It requires that the
branch does not yet exist, and the new branch is created upon commit.

Gé

[Ron Wilson]

Post by Gé Weijers
If you create the branch first you cannot forget later and commit to the
wrong branch.>

I beg to differ!  Just this past Friday, I did three separate commits to
SQLite that went into the wrong branch even though the correct branch
already existed.

A hazard of working with multiple branches. All too easy to make edits
to the wrong working copy or to forget to update your working copy to
the intended branch.

As has been said many times, Been there, done that.

Post by Gé Weijers
$ fossil branch next espresso-feature

That's an interesting feature request.  I'll take it under consideration...

What about allowing a "null commit" on branch? That way,

fossil commit -branch new-branch

could be a universal one-step branch starter.

[Richard Hipp]

Post by Richard Hipp

Post by Richard Hipp

Post by Gé Weijers
$ fossil branch next espresso-feature

That's an interesting feature request. I'll take it under

consideration...
What about allowing a "null commit" on branch? That way,
fossil commit -branch new-branch
could be a universal one-step branch starter.

I think you can already do that just by adding the --force flag:

fossil commit --branch new-branch --force

And I think the "fossil branch new new-branch" command is simply syntactic
sugar for the above.

Post by Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[a***@mail.com]

It is more like a logical process. You want to work on something, create a branch, work on it and commit. If you have to create a branch when committing, you will have to remember if this is first commit in that branch or subsequent. You commandline will also be different for first commit that creates the branch - not good for scripting or for 3rd party GUIs - IDEs?

- altu

----- Original Message -----
From: Richard Hipp
Sent: 08/09/11 08:28 PM
Subject: [fossil-users] Why do people create branches as a separate step? Was: Unable to sign manifest

fossil branch new Test 5947928ba****

Change the subject: Please help me to understand why people want to create
a new branch before adding changes to that branch, rather than just waiting
until they check-in their edits? I'm not being sarcastic or critical here.
A lot of people do this and I sincerely want to understand the motivation.
(1) ... edit files
(2) fossil commit -branch new-branch
(1) fossil branch new new-branch
(2) fossil update new-branch
(3) ... edit files
(4) fossil commit
That seems like so much more trouble. What am I missing? Is it that people
are unaware that they can make edits that are destined to go into a branch
before that branch actually exists? Do I need to improve on the
documentation? Or does creating the branch first, before making file edits,
just fit most peoples mental model better? Are there some advantages to
creating branches in advance that I am missing?
Part of the motivation for this question is that, because I never use
"fossil branch new" myself, there tend to be more bugs in that command than
in the other commands that I use daily. If there is a good reason to do
"fossil branch new" then maybe I'll start using it myself and those bugs
will get fixed sooner. Or if not, maybe I'll deprecate "fossil branch new"
- or at least print a warning and ask for confirmation: "Creating branches
ahead of check-ins is unnecessary. Are you sure you want to do this? (y/N)"
Please explain. Thanks!
--
D. Richard Hipp

[Stephan Beal]

Post by a***@mail.com
It is more like a logical process. You want to work on something, create a
branch, work on it and commit. If you have to create a branch when
committing, you will have to remember if this is first commit in that branch
or subsequent. You commandline will also be different for first commit that
creates the branch - not good for scripting or for 3rd party GUIs - IDEs?

+1. Very not good for people with the memory of a goldfish (like me).
Delaying the decision to branch until commit-time is just another pothole
i'd fall into.

[Will Duquette]

Post by t***@compumation.com
Change the subject: Please help me to understand why people want to create a new branch before adding changes to that branch, rather than just waiting until they check-in their edits? I'm not being sarcastic or critical here. A lot of people do this and I sincerely want to understand the motivation.

I'd tend to do this so that I don't forget to add "-branch new-branch" when I commit. If I'm using a different branch, it's because the development context has changed; I want the state of my work area to match the development context. If I start editing files while planning to "fossil commit -branch new-branch", then my work area doesn't match my development context. If I create the new branch explicitly, then I've changed my development context in my head AND in my work area.

Will

Mr. Will Duquette, OP
will -at- wjduquette dot com
http://foothills.wjduquette.com/blog

[Stephan Beal]

...development context. If I create the new branch explicitly, then I've
changed my development context in my head AND in my work area.

Thank you for so elegantly describing what i was unable to express nearly as
well :).

[Steve Landers]

...development context. If I create the new branch explicitly, then I've changed my development context in my head AND in my work area.
Thank you for so elegantly describing what i was unable to express nearly as well :).

+1

--Steve