Fossil SCM

Updated the fossil-v-git doc to talk about "fossil patch" in addition to "fossil bundle".

wyoung 2021-08-31 13:14 trunk
Commit e3e06d31f51d6b49302b4278b8e8babcb19332f0cf2d56a58fce6a3e0b06f595
1 file changed +8 -3
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -441,11 +441,11 @@
441441
<li><p><b>No easy drive-by contributions:</b> Git
442442
[https://www.git-scm.com/docs/git-request-pull|pull requests] offer
443443
a low-friction path to accepting
444444
[https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
445445
contributions]. Fossil's closest equivalent is its unique
446
- [/help?cmd=bundle|bundle] feature, which requires higher engagement
446
+ [/help?cmd=bundle|bundle] and [/help?cmd=patch|patch] features, which require higher engagement
447447
than firing off a PR.⁷ This difference comes directly from the
448448
initial designed purpose for each tool: the SQLite project doesn't
449449
accept outside contributions from previously-unknown developers, but
450450
the Linux kernel does.</p></li>
451451
@@ -924,12 +924,17 @@
924924
despite using a roughly similar amount of high-level scripting code
925925
because its interpreters are compact and built into Fossil itself.
926926
927927
<li><p>Both Fossil and Git support
928928
[https://en.wikipedia.org/wiki/Patch_(Unix)|<tt>patch(1)</tt>
929
- files], a common way to allow drive-by contributions, but it's a
929
+ files] — unified diff formatted output — for accepting drive-by contributions, but it's a
930930
lossy contribution path for both systems. Unlike Git PRs and Fossil
931931
bundles, patch files collapse multiple checkins together, they don't
932932
include check-in comments, and they cannot encode changes made above
933933
the individual file content layer: you lose branching decisions,
934
- tag changes, file renames, and more when using patch files.</p></li>
934
+ tag changes, file renames, and more when using patch files. Fossil
935
+ 2.16 adds [./patchcmd.md | a <tt>fossil patch</tt> command] that
936
+ also solves these problems, but it is because it works like a Fossil
937
+ bundle, only for uncommitted changes; it doesn't use Larry Wall's
938
+ <tt>patch</tt> tool to apply unified diff output to the receiving
939
+ Fossil checkout.</p></li>
935940
</ol></i></small>
936941
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -441,11 +441,11 @@
441 <li><p><b>No easy drive-by contributions:</b> Git
442 [https://www.git-scm.com/docs/git-request-pull|pull requests] offer
443 a low-friction path to accepting
444 [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
445 contributions]. Fossil's closest equivalent is its unique
446 [/help?cmd=bundle|bundle] feature, which requires higher engagement
447 than firing off a PR.⁷ This difference comes directly from the
448 initial designed purpose for each tool: the SQLite project doesn't
449 accept outside contributions from previously-unknown developers, but
450 the Linux kernel does.</p></li>
451
@@ -924,12 +924,17 @@
924 despite using a roughly similar amount of high-level scripting code
925 because its interpreters are compact and built into Fossil itself.
926
927 <li><p>Both Fossil and Git support
928 [https://en.wikipedia.org/wiki/Patch_(Unix)|<tt>patch(1)</tt>
929 files], a common way to allow drive-by contributions, but it's a
930 lossy contribution path for both systems. Unlike Git PRs and Fossil
931 bundles, patch files collapse multiple checkins together, they don't
932 include check-in comments, and they cannot encode changes made above
933 the individual file content layer: you lose branching decisions,
934 tag changes, file renames, and more when using patch files.</p></li>
 
 
 
 
 
935 </ol></i></small>
936
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -441,11 +441,11 @@
441 <li><p><b>No easy drive-by contributions:</b> Git
442 [https://www.git-scm.com/docs/git-request-pull|pull requests] offer
443 a low-friction path to accepting
444 [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
445 contributions]. Fossil's closest equivalent is its unique
446 [/help?cmd=bundle|bundle] and [/help?cmd=patch|patch] features, which require higher engagement
447 than firing off a PR.⁷ This difference comes directly from the
448 initial designed purpose for each tool: the SQLite project doesn't
449 accept outside contributions from previously-unknown developers, but
450 the Linux kernel does.</p></li>
451
@@ -924,12 +924,17 @@
924 despite using a roughly similar amount of high-level scripting code
925 because its interpreters are compact and built into Fossil itself.
926
927 <li><p>Both Fossil and Git support
928 [https://en.wikipedia.org/wiki/Patch_(Unix)|<tt>patch(1)</tt>
929 files] — unified diff formatted output — for accepting drive-by contributions, but it's a
930 lossy contribution path for both systems. Unlike Git PRs and Fossil
931 bundles, patch files collapse multiple checkins together, they don't
932 include check-in comments, and they cannot encode changes made above
933 the individual file content layer: you lose branching decisions,
934 tag changes, file renames, and more when using patch files. Fossil
935 2.16 adds [./patchcmd.md | a <tt>fossil patch</tt> command] that
936 also solves these problems, but it is because it works like a Fossil
937 bundle, only for uncommitted changes; it doesn't use Larry Wall's
938 <tt>patch</tt> tool to apply unified diff output to the receiving
939 Fossil checkout.</p></li>
940 </ol></i></small>
941

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button