68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
-
-
-
-
-
-
+
|
</tr>
<tr>
<td>Designed for Linux kernel development</td>
<td>Designed for SQLite development</td>
<td><a href="#scale">2.5.2 ↓</a></td>
</tr>
<tr>
<td>Many contributors</td>
<td>Select contributors</td>
<td><a href="#contrib">2.5.3 ↓</a></td>
</tr>
<tr>
<td><a href="#branches">2.5.4 ↓</a></td>
<td><a href="#branches">2.5.3 ↓</a></td>
</tr>
<tr>
<td>One check-out per repository</td>
<td>Many check-outs per repository</td>
<td><a href="#checkouts">2.6 ↓</a></td>
</tr>
<tr>
|
589
590
591
592
593
594
595
596
597
598
599
600
601
602
|
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
|
+
+
+
|
by every contributor to Linux: such extreme visibility does not scale
well. Contrast Fossil, which was written for the cathedral-style SQLite project
and its handful of active committers. Seeing all
changes on all branches all at once helps keep the whole team
up-to-date with what everybody else is doing, resulting in a more
tightly focused and cohesive implementation.
Parts of this section are [https://fossil-scm.org/forum/forumpost/5961e969fa|disputed]
by [https://github.com/olorin37|Jakub A. G.].
<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
Because Git commingles the repository data with the initial checkout of
that repository, the default mode of operation in Git is to stick to that
single work/repo tree, even when that's a shortsighted way of working.
|
658
659
660
661
662
663
664
665
666
667
668
669
670
671
|
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
|
+
+
|
Disk space is cheap. Having several working directories — each with its
own local state — makes switching versions cheap and fast.
Plus,
<tt>cd</tt> is faster to type than <tt>git checkout</tt> or <tt>fossil
update</tt>.
Parts of this section are [https://fossil-scm.org/forum/forumpost/5961e969fa|disputed]
by [https://github.com/olorin37|Jakub A. G.].
<h3 id="history">2.7 What you should have done vs. What you actually did</h3>
Git puts a lot of emphasis on maintaining
a "clean" check-in history. Extraneous and experimental branches by
individual developers often never make it into the main repository.
Branches may be rebased before being pushed to make
|