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

[Richard Hipp]

On Tue, Aug 9, 2011 at 10:28 AM, tper...@compumation.com <tper...@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
d...@sqlite.org

[Gour-Gadadhara Dasa]

On Tue, 9 Aug 2011 10:58:02 -0400
Richard Hipp <d...@sqlite.org> wrote:

> 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

--
“In the material world, conceptions of good and bad are
all mental speculations…” (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[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

[Joshua Paine]

On 8/9/2011 10:58 AM, Richard Hipp wrote:
> 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
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Joshua Paine]

On 8/9/2011 11:04 AM, Gour-Gadadhara Dasa wrote:
> 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.

[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?

[Joshua Paine]

On 8/9/2011 11:19 AM, Matt Welland wrote:
> Note: It is annoying to me that "fossil branch new foo" won't simply
> branch from the current node.

+1

> 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.

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

[Stephan Beal]

On Tue, Aug 9, 2011 at 4:58 PM, Richard Hipp <d...@sqlite.org> wrote:

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.

 

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.

 

Please explain.  Thanks!

It's simply a different way of doing it.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

[Konstantin Khomoutov]

On Tue, 9 Aug 2011 17:04:04 +0200
Gour-Gadadhara Dasa <go...@atmarama.net> wrote:

> > 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.

[Lluís Batlle i Rossell]

On Tue, Aug 09, 2011 at 10:58:02AM -0400, Richard Hipp wrote:
> On Tue, Aug 9, 2011 at 10:28 AM, tper...@compumation.com <
> tper...@compumation.com> wrote:
> 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

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.

[Konstantin Khomoutov]

On Tue, 9 Aug 2011 08:19:46 -0700
Matt Welland <esti...@gmail.com> wrote:

> 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.

> 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.

[Lluís Batlle i Rossell]

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

[Lluís Batlle i Rossell]

On Tue, Aug 09, 2011 at 11:27:09AM -0400, Joshua Paine wrote:
> On 8/9/2011 11:19 AM, Matt Welland wrote:
> > Note: It is annoying to me that "fossil branch new foo" won't simply
> > branch from the current node.
>
> +1
>
> > 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.

[Lluís Batlle i Rossell]

On Tue, Aug 09, 2011 at 10:58:02AM -0400, Richard Hipp wrote:

> On Tue, Aug 9, 2011 at 10:28 AM, tper...@compumation.com <
> tper...@compumation.com> wrote:
> (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.

2011/8/9 Lluís Batlle i Rossell <viri...@gmail.com>

[Ron Wilson]

On Tue, Aug 9, 2011 at 10:58 AM, Richard Hipp <d...@sqlite.org> wrote:
> 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?

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]

On Tue, Aug 9, 2011 at 9:25 AM, Ron Wilson <ronw...@gmail.com> wrote:

On Tue, Aug 9, 2011 at 10:58 AM, Richard Hipp <d...@sqlite.org> wrote:
> 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?

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]

On 9 Aug 2011, at 18:15, Matt Welland wrote:
>
> **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

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/

[Mike Meyer]

On Tue, Aug 9, 2011 at 8:35 AM, Konstantin Khomoutov <flat...@users.sourceforge.net> wrote:

On Tue, 9 Aug 2011 08:19:46 -0700
Matt Welland <esti...@gmail.com> wrote:

> 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.

  > > 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

[tper...@compumation.com]

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

[tper...@compumation.com]

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

Thanks,
Tony Perovic

[Lluís Batlle i Rossell]

On Tue, Aug 09, 2011 at 01:01:55PM -0500, tper...@compumation.com wrote:
> 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.

[Brian Cottingham]

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

2011/8/9 Lluís Batlle i Rossell <viri...@gmail.com>

On Tue, Aug 09, 2011 at 01:01:55PM -0500, tper...@compumation.com wrote:

[Lluís Batlle i Rossell]

On Tue, Aug 09, 2011 at 02:04:36PM -0400, Brian Cottingham wrote:
> 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.

[Gé Weijers]

On Tue, 9 Aug 2011, Richard Hipp wrote:

> 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]

On Tue, Aug 09, 2011 at 11:33:19AM -0700, Gé Weijers wrote:
>
>
> On Tue, 9 Aug 2011, Richard Hipp wrote:
>
> >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.

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.

[Richard Hipp]

On Tue, Aug 9, 2011 at 2:33 PM, Gé Weijers <g...@weijers.org> wrote:

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.

> $ fossil branch next espresso-feature

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

[Gé Weijers]

On Tue, 9 Aug 2011, Lluís Batlle i Rossell wrote:

>> 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é

[Gé Weijers]

On Tue, 9 Aug 2011, Richard Hipp wrote:

>> On Tue, Aug 9, 2011 at 2:33 PM, Gé Weijers <g...@weijers.org> wrote:
>>
>> 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é

[altu...@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
> 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, tper...@compumation.com <
> tper...@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
> d...@sqlite.org
>

_______________________________________________

[Stephan Beal]

On Wed, Aug 10, 2011 at 4:50 AM, <altu...@mail.com> wrote:

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.

[Ron Wilson]

On Tue, Aug 9, 2011 at 2:47 PM, Richard Hipp <d...@sqlite.org> wrote:
> On Tue, Aug 9, 2011 at 2:33 PM, Gé Weijers <g...@weijers.org> wrote:
>> 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.

>
>> $ 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]

On Wed, Aug 10, 2011 at 1:39 PM, Ron Wilson <ronw...@gmail.com> wrote:

>
>> $ 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.

 

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

[Will Duquette]

On Aug 9, 2011, at 7:58 AM, Richard Hipp wrote:

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]

On Thu, Aug 11, 2011 at 1:35 AM, Will Duquette <wi...@wjduquette.com> wrote:

...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]

On 11/08/2011, at 8:02 AM, Stephan Beal wrote:

On Thu, Aug 11, 2011 at 1:35 AM, Will Duquette <wi...@wjduquette.com> wrote:

...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