Fossil

Check-in [ff428f3e09]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Linking to the new docs from fossil-v-git.wiki, simplifying it a bit.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: ff428f3e091c9da98f39c5c34088b166de6f81cfe1e9e1b8fca9303338128d77
User & Date: wyoung 2020-11-02 00:38:01.066
Context
2020-11-02
00:38
Typo fix in previous check-in: a1626b3028 user: wyoung tags: trunk
00:38
Linking to the new docs from fossil-v-git.wiki, simplifying it a bit. check-in: ff428f3e09 user: wyoung tags: trunk
00:34
Added the "Git Worktrees" section to the gitusers doc, which acts as a complement to the "multiple check-out directories" section of the new ckout-workflow.md doc. It gives us a place to talk about git-worktree and git clone --separate-git-dir. check-in: 31f8a835da user: wyoung tags: trunk
Changes
Unified Diff Ignore Whitespace Patch
Changes to www/fossil-v-git.wiki.
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659

660
661
662
663
664
665
666
667
directory, and this is also often done. It is simply that there is no
inherent penalty to either choice in Fossil as there is in Git. The
standard advice is to use a switch-in-place workflow in Fossil when
the disturbance from switching branches is small, and to use multiple
checkouts when you have long-lived working branches that are different
enough that switching in place is disruptive.

You can use Git in the Fossil style, either by manually symlinking the
<tt>.git</tt> directory from one working directory to another or by use
of the <tt>[https://git-scm.com/docs/git-worktree|git-worktree]</tt>
feature. Nevertheless, Git's default tie between working directory and
repository means the standard method for working with a Git repo is to
have one working directory only. Most Git tutorials teach this style, so
it is how most people learn to use Git. Because relatively few people
use Git with multiple working directories per repository, there are
[https://duckduckgo.com/?q=git+worktree+problem | several known
problems] with that way of working, problems which don't happen in Fossil because of

the clear separation between repository and working directory.

This distinction matters because switching branches inside a single working directory loses local context
on each switch.

For instance, in any software project where the runnable program must be
built from source files, you invalidate build objects on each switch,
artificially increasing the time required to switch versions. Most obviously, this







|
<
<
|






>
|







643
644
645
646
647
648
649
650


651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
directory, and this is also often done. It is simply that there is no
inherent penalty to either choice in Fossil as there is in Git. The
standard advice is to use a switch-in-place workflow in Fossil when
the disturbance from switching branches is small, and to use multiple
checkouts when you have long-lived working branches that are different
enough that switching in place is disruptive.

While you can [./gitusers.md#worktree | use Git in the Fossil style],


feature, Git's default tie between working directory and
repository means the standard method for working with a Git repo is to
have one working directory only. Most Git tutorials teach this style, so
it is how most people learn to use Git. Because relatively few people
use Git with multiple working directories per repository, there are
[https://duckduckgo.com/?q=git+worktree+problem | several known
problems] with that way of working, problems which don't happen in Fossil because of
the clear [./ckout-workflows.md | separation] between a Fossil repository and
each working directory.

This distinction matters because switching branches inside a single working directory loses local context
on each switch.

For instance, in any software project where the runnable program must be
built from source files, you invalidate build objects on each switch,
artificially increasing the time required to switch versions. Most obviously, this