On Oct 21, 2016, at 7:31 PM, Nikita Borodikhin <elit...@gmail.com> wrote:
> 
> I would like to be able to commit only needed changes:

So say:

   $ fossil ci Makefile state_machine.c

It’s actually less typing than defining a changelist and then committing the 
changelist.

If you’re not certain about the changes in those two files, you can “fossil 
diff” just those two files:

  $ fossil diff Makefile state_machine.c | less

Then edit the command from history to change “diff” to “ci” when you’re 
satisfied.

> Sure, this example is a little bit too simple, but you get the idea.  
> Unfortunately, it could not be stopped easily with branhces.

Here’s the alternative with branches:

    $ fossil ci --branch my-new-feature state1.c
    $ fossil up trunk
    $ fossil ci --branch my-other-new-feature state2.c
    $ fossil up trunk
    $ fossil ci

It’s a bit more complex, but has a different effect, so you can’t compare them 
apples-to-apples.  Here, we’re saying that state1.c and state2.c contain 
partially finished features which we want to set aside so that we can focus on 
Makefile and state_machine.c.  Maybe we’ll make more changes before checking 
the changes in.

You can use the stash instead if you don’t like branches:

    $ fossil stash save state1.c
    $ fossil stash save state2.c    # yes, separate commands! 
    $ fossil ci

It’s simpler in that you don’t have to keep returning to trunk to revert the 
changes, but if you’re working on a team, now you have the Guy In the Room 
Problem:

    https://www.youtube.com/watch?v=oY6BCHqEbyc

If you’re not working on a team, the main disadvantage of the stash over 
branches is that it’s local to a particular open checkout, so that if you’re 
working on multiple machines or have multiple checkouts, you can’t simply 
switch branches to see your in-progress feature, you have to somehow copy the 
files over manually.

Another problem with the stash is that if you say “fossil close,” it will offer 
to throw away your stash, which is irrecoverable if you accept.  At least with 
branches, you have a copy of the code durably archived.

There’s no shame in having partially-working code checked in on a branch.  
Broken code on the trunk is a problem for many reasons, but it’s quite common 
to make many checkins on a branch to bring the initial checkin on that branch 
into shape suitable for merging back into the trunk.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to