Fossil SCM
Clarified the matter of git worktrees in the fossil-v-git.wiki doc, which then allows removal of the second "disputed" comment.
Commit
2bfb72a63edb41df7d1667e735087caa69a912ba6358222f2e2e7abd4c7a3a2f
Parent
4146f2d04ef8208…
1 file changed
+17
-12
+17
-12
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -629,20 +629,28 @@ | ||
| 629 | 629 | standard advice is to use a switch-in-place workflow in Fossil when |
| 630 | 630 | the disturbance from switching branches is small, and to use multiple |
| 631 | 631 | checkouts when you have long-lived working branches that are different |
| 632 | 632 | enough that switching in place is disruptive. |
| 633 | 633 | |
| 634 | -While you can [./gitusers.md#worktree | use Git in the Fossil style], | |
| 635 | -Git's default tie between working directory and | |
| 636 | -repository means the standard method for working with a Git repo is to | |
| 637 | -have one working directory only. Most Git tutorials teach this style, so | |
| 638 | -it is how most people learn to use Git. Because relatively few people | |
| 639 | -use Git with multiple working directories per repository, there are | |
| 634 | +While you can [./gitusers.md#worktree | use Git in the Fossil style] via | |
| 635 | +its worktree feature, tutorials continue to teach the style of having | |
| 636 | +one working directory only. Git can even fight you on this, as when | |
| 637 | +working with a forked repository; it is best to have independent clones | |
| 638 | +of the upstream and your fork, to allow separate "remote" lists and | |
| 639 | +such. This can result in two working directories but each having a | |
| 640 | +captive repo clone each, which isn't in the spirit of <tt>git | |
| 641 | +worktree</tt> at all. Yet, it beats the alternative, which then | |
| 642 | +highlights a gap in the model of diverging and re-converging forks. | |
| 643 | +Ideally, Git would let you create one of these forks as a worktree while | |
| 644 | +maintaining a strong separation between your fork and the upstream repo, | |
| 645 | +but it ends up being too much hassle to bother with. | |
| 646 | + | |
| 647 | +There are | |
| 640 | 648 | [https://duckduckgo.com/?q=git+worktree+problem | several known |
| 641 | -problems] with that way of working, problems which don't happen in Fossil because of | |
| 642 | -the clear [./ckout-workflows.md | separation] between a Fossil repository and | |
| 643 | -each working directory. | |
| 649 | +problems] with the single worktree style, ones which don't happen in | |
| 650 | +Fossil because of the clear [./ckout-workflows.md | separation] between | |
| 651 | +a Fossil repository and each working directory. | |
| 644 | 652 | |
| 645 | 653 | This distinction matters because switching branches inside a single working directory loses local context |
| 646 | 654 | on each switch. |
| 647 | 655 | |
| 648 | 656 | For instance, in any software project where the runnable program must be |
| @@ -675,13 +683,10 @@ | ||
| 675 | 683 | |
| 676 | 684 | Plus, |
| 677 | 685 | <tt>cd</tt> is faster to type than <tt>git checkout</tt> or <tt>fossil |
| 678 | 686 | update</tt>. |
| 679 | 687 | |
| 680 | -Parts of this section are [https://fossil-scm.org/forum/forumpost/5961e969fa|disputed] | |
| 681 | -by [https://github.com/olorin37|Jakub A. G.]. | |
| 682 | - | |
| 683 | 688 | <h3 id="history">2.7 What you should have done vs. What you actually did</h3> |
| 684 | 689 | |
| 685 | 690 | Git puts a lot of emphasis on maintaining |
| 686 | 691 | a "clean" check-in history. Extraneous and experimental branches by |
| 687 | 692 | individual developers often never make it into the main repository. |
| 688 | 693 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -629,20 +629,28 @@ | |
| 629 | standard advice is to use a switch-in-place workflow in Fossil when |
| 630 | the disturbance from switching branches is small, and to use multiple |
| 631 | checkouts when you have long-lived working branches that are different |
| 632 | enough that switching in place is disruptive. |
| 633 | |
| 634 | While you can [./gitusers.md#worktree | use Git in the Fossil style], |
| 635 | Git's default tie between working directory and |
| 636 | repository means the standard method for working with a Git repo is to |
| 637 | have one working directory only. Most Git tutorials teach this style, so |
| 638 | it is how most people learn to use Git. Because relatively few people |
| 639 | use Git with multiple working directories per repository, there are |
| 640 | [https://duckduckgo.com/?q=git+worktree+problem | several known |
| 641 | problems] with that way of working, problems which don't happen in Fossil because of |
| 642 | the clear [./ckout-workflows.md | separation] between a Fossil repository and |
| 643 | each working directory. |
| 644 | |
| 645 | This distinction matters because switching branches inside a single working directory loses local context |
| 646 | on each switch. |
| 647 | |
| 648 | For instance, in any software project where the runnable program must be |
| @@ -675,13 +683,10 @@ | |
| 675 | |
| 676 | Plus, |
| 677 | <tt>cd</tt> is faster to type than <tt>git checkout</tt> or <tt>fossil |
| 678 | update</tt>. |
| 679 | |
| 680 | Parts of this section are [https://fossil-scm.org/forum/forumpost/5961e969fa|disputed] |
| 681 | by [https://github.com/olorin37|Jakub A. G.]. |
| 682 | |
| 683 | <h3 id="history">2.7 What you should have done vs. What you actually did</h3> |
| 684 | |
| 685 | Git puts a lot of emphasis on maintaining |
| 686 | a "clean" check-in history. Extraneous and experimental branches by |
| 687 | individual developers often never make it into the main repository. |
| 688 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -629,20 +629,28 @@ | |
| 629 | standard advice is to use a switch-in-place workflow in Fossil when |
| 630 | the disturbance from switching branches is small, and to use multiple |
| 631 | checkouts when you have long-lived working branches that are different |
| 632 | enough that switching in place is disruptive. |
| 633 | |
| 634 | While you can [./gitusers.md#worktree | use Git in the Fossil style] via |
| 635 | its worktree feature, tutorials continue to teach the style of having |
| 636 | one working directory only. Git can even fight you on this, as when |
| 637 | working with a forked repository; it is best to have independent clones |
| 638 | of the upstream and your fork, to allow separate "remote" lists and |
| 639 | such. This can result in two working directories but each having a |
| 640 | captive repo clone each, which isn't in the spirit of <tt>git |
| 641 | worktree</tt> at all. Yet, it beats the alternative, which then |
| 642 | highlights a gap in the model of diverging and re-converging forks. |
| 643 | Ideally, Git would let you create one of these forks as a worktree while |
| 644 | maintaining a strong separation between your fork and the upstream repo, |
| 645 | but it ends up being too much hassle to bother with. |
| 646 | |
| 647 | There are |
| 648 | [https://duckduckgo.com/?q=git+worktree+problem | several known |
| 649 | problems] with the single worktree style, ones which don't happen in |
| 650 | Fossil because of the clear [./ckout-workflows.md | separation] between |
| 651 | a Fossil repository and each working directory. |
| 652 | |
| 653 | This distinction matters because switching branches inside a single working directory loses local context |
| 654 | on each switch. |
| 655 | |
| 656 | For instance, in any software project where the runnable program must be |
| @@ -675,13 +683,10 @@ | |
| 683 | |
| 684 | Plus, |
| 685 | <tt>cd</tt> is faster to type than <tt>git checkout</tt> or <tt>fossil |
| 686 | update</tt>. |
| 687 | |
| 688 | <h3 id="history">2.7 What you should have done vs. What you actually did</h3> |
| 689 | |
| 690 | Git puts a lot of emphasis on maintaining |
| 691 | a "clean" check-in history. Extraneous and experimental branches by |
| 692 | individual developers often never make it into the main repository. |
| 693 |