On Oct 21, 2016, at 7:31 PM, Nikita Borodikhin <[email protected]> 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
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
