On Nov 3, 2015, at 5:59 AM, Michal Suchanek <[email protected]> wrote:
>
> On 2 November 2015 at 20:40, Richard Hipp <[email protected]> wrote:
>> On 11/2/15, Michal Suchanek <[email protected]> wrote:
>>>
>>> when you
>>> want to separate the changes you want to commit and changes you want
>>> to ... keep uncommitted to do more work on them this is quite
>>> useful. And don't tell me nobody ever mixes unrelated and possibly
>>> conflicting changes in the same working directory.
>>
>> People do that. But it is much more easily accomplished by simply
>> listing the files you want to commit on the "commit" command line.
>
> Unless you have unrelated changes in the same file, of course.
I made a proposal on the list here recently for a feature that would let you
extract pieces of a diff from the stash interactively. That would give you the
effect of cherrypicking individual changes with the git staging area without
making it a mandatory step in every checkin.
I call the Git staging area “mandatory” because from the perspective of Fossil
with autosync enabled — the default — it is not a necessary part of using a
DVCS.
Obviously you can use Git without ever pushing, in which case everyday Git use
looks a fair bit like everyday Fossil use. But, if that’s a reasonable
solution to the usability problem, one wonders why you aren’t just using a
non-distributed VCS.
By keeping your local and remote repos in sync at every checkin via its
autosync feature, Fossil gives you most of the the everyday usage simplicity of
a non-distributed VCS while still being a DVCS. Git keeps you constantly aware
that your local repo and the remote one are frequently out of sync.
Git was designed with that as a *feature*, not as an unfortunate consequence of
some other design decision. It is so designed because in the Linux kernel
development community, people often go off on their own tangents for days or
months, then only later publish something they want others to take a look at.
That’s great if your developers are all intended to go off on solo tangents for
extended stretches.
Fossil, though, is designed for teams that actually work *together* on things.
You can still go off on a tangent with a branch, if you want, but in normal
use, even that is still visible to the others sync’d to that repo. Private
branches and such are available in Fossil, but they’re not the default, as with
Git.
No one here is saying that Git can’t work, or is unusable. What we’re arguing
here are the consequences of the defaults. Defaults matter.
>> you should not be checking-in untested changes.
>> The proper way to do incremental check-ins is to stash the whole lot,
>> then pull out individual pieces from the stash and test and commit
>> them separately.
>
> And that's what the staging area allows for easily.
In my experience, finding that you’ve done a whole bunch of mutually unrelated
work without checking in is the exception case.
It’s a sign of unclear thinking. Your DVCS should not be designed to support
unclear thinking through its primary user interfaces. Your DVCS should be
designed so that unclear thinking carries a consequence, to encourage you to
think more clearly in the future.
Manually disentangling overlapping patches is that consequence, in Fossil’s
case.
Fossil encourages frequent checkins. When frequent checkins aren’t possible,
it makes branching and merging easy, so you can isolate your unclear thinking
while you clarify your solution.
>> Note that detached head state is impossible in Fossil and in most
>> other VCSs. (Unsure about Hg.)
>
> Detached head state is the state which you enter when you check out
> some random commit id…Any VCS can do that.
Nope:
mkdir tmp
cd tmp
f clone http://fossil-scm.org ~/fossil.fossil
f open ~/fossil.fossil
f up 485aa80625acdb # some random commit ID
echo '/* silly change */' >> src/shell.c
f ci
Result? Error:
would fork. "update" first or use --allow-fork.
So no, Fossil does not enter detached head state when you try to check in
something in the middle of a branch.
If you follow Fossil’s recommendation (“update” first) your change is merged
into the tip of that branch, automatically if possible. Then there is no
problem.
If instead you force Fossil to accept the checkin with --allow-fork, you end up
with a dual-tipped branch, which doesn’t lose information, because the forked
branch is still attached to the rest of the Fossil tree.
Alternately, you can check your changes in with --branch, which is functionally
the same as --allow-fork, except that the new branch has its own name from the
start, so you don’t end up with a dual-tipped branch, the very thing Fossil is
warning you about here.
Furthermore, committing while in detached head state in Git does not create a
dual-tippped branch, as in Fossil. It creates a free-floating branch,
disconnected from everything else. If you then move to a named branch (e.g.
“git checkout master”) you *lose your work* because Git sees that you have
local changes that don’t refer to anything in the repo.
Part of this gets back to drh’s earlier point about Git giving the developer
too much state to keep track of: it often happens because your local branch set
and the remote branch set aren’t the same.
Fossil avoids that particular problem with autosync. The only way I’ve ever
had a dual-tipped Fossil branch is because I was committing to a branch while
disconnected from the Internet, so Fossil couldn’t warn me that someone else
was moving that branch along at the same time, so when it came time to merge,
Fossil now had two different branches called foo, and needed manual help fixing
it.
And let’s be clear: even in in the worst case above, the dual-tipped branch,
Fossil doesn’t lose information. The only reason it’s even a problem is that
commands like “fossil up branch-name” are ambiguous while there are two
branches with that name. As soon as someone heals the fork or gives the new
branch a unique name, there is no longer a problem.
> It's completely fine to allow detached head state
Fossil completely avoids it. It is clearly not a necessary attribute of a DVCS.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
