Fossil SCM
In the check-in names documentation, mention that some prefixes can be chained.
Commit
ef9e42acb84f6e20a325b7121be077cee62721f5a19871feb6ea9648745e7608
Parent
dfb1234f937c490…
1 file changed
+18
-9
+18
-9
| --- www/checkin_names.wiki | ||
| +++ www/checkin_names.wiki | ||
| @@ -98,13 +98,13 @@ | ||
| 98 | 98 | is not anything special: it is simply a sequence of check-ins that |
| 99 | 99 | share a common tag, so the same mechanism that resolves tag names |
| 100 | 100 | also resolves branch names. |
| 101 | 101 | |
| 102 | 102 | <a id="tagpfx"></a> |
| 103 | -Note also that there can — in theory, if rarely in practice — be an ambiguity between tag names | |
| 104 | -and canonical names. Suppose, for example, you had a check-in with | |
| 105 | -the canonical name deed28aa99… and you | |
| 103 | +Note also that there can — in theory, if rarely in practice — be an ambiguity | |
| 104 | +between tag names and canonical names. Suppose, for example, you had a | |
| 105 | +check-in with the canonical name deed28aa99… and you | |
| 106 | 106 | also happened to have tagged a different check-in with "deed2". If |
| 107 | 107 | you use the "deed2" name, does it choose the canonical name or the tag |
| 108 | 108 | name? In such cases, you can prefix the tag name with "tag:". |
| 109 | 109 | For example: |
| 110 | 110 | |
| @@ -183,12 +183,12 @@ | ||
| 183 | 183 | |
| 184 | 184 | <blockquote> |
| 185 | 185 | http://fossil-scm.org/home/doc/<b>trunk</b>/www/index.wiki |
| 186 | 186 | </blockquote> |
| 187 | 187 | |
| 188 | -The bold component of that URL is a check-in name. To see the stored | |
| 189 | -content of the Fossil website repository as of January 1, 2009, one has merely to change | |
| 188 | +The bold component of that URL is a check-in name. To see the stored content | |
| 189 | +of the Fossil website repository as of January 1, 2009, one has merely to change | |
| 190 | 190 | the URL to the following: |
| 191 | 191 | |
| 192 | 192 | <blockquote> |
| 193 | 193 | http://fossil-scm.org/home/doc/<b>2009-01-01</b>/www/index.wiki |
| 194 | 194 | </blockquote> |
| @@ -202,13 +202,13 @@ | ||
| 202 | 202 | A check-in name can also take the form of a tag or branch name followed by |
| 203 | 203 | a colon and then a timestamp. The combination means to take the most |
| 204 | 204 | recent check-in with the given tag or branch which is not more recent than |
| 205 | 205 | the timestamp. So, for example: |
| 206 | 206 | |
| 207 | -<blockquote> | |
| 207 | +<blockquote><tt> | |
| 208 | 208 | fossil update trunk:2010-07-01T14:30 |
| 209 | -</blockquote> | |
| 209 | +</tt></blockquote> | |
| 210 | 210 | |
| 211 | 211 | Would cause Fossil to update the working check-out to be the most recent |
| 212 | 212 | check-in on the trunk that is not more recent than 14:30 (UTC) on |
| 213 | 213 | July 1, 2010. |
| 214 | 214 | |
| @@ -218,13 +218,13 @@ | ||
| 218 | 218 | last check-in on the parent branch prior to the beginning of the branch. |
| 219 | 219 | Such a label is useful, for example, in computing all diffs for a single |
| 220 | 220 | branch. The following example will show all changes in the hypothetical |
| 221 | 221 | branch "xyzzy": |
| 222 | 222 | |
| 223 | -<blockquote> | |
| 223 | +<blockquote><tt> | |
| 224 | 224 | fossil diff --from root:xyzzy --to xyzzy |
| 225 | -</blockquote> | |
| 225 | +</tt></blockquote> | |
| 226 | 226 | |
| 227 | 227 | <a id="merge-in"></a> |
| 228 | 228 | That doesn't do what you might expect after you merge the parent |
| 229 | 229 | branch's changes into the child branch: the above command will include |
| 230 | 230 | changes made on the parent branch as well. |
| @@ -234,10 +234,19 @@ | ||
| 234 | 234 | the most recent merge-in point for that branch. |
| 235 | 235 | The resulting diff will then show only the changes in |
| 236 | 236 | the branch itself, omitting |
| 237 | 237 | any changes that have already been merged in from the parent branch. |
| 238 | 238 | |
| 239 | +The prefixes "<tt>root:</tt>" and "<tt>merge-in:</tt>" can be chained: one | |
| 240 | +can say for example | |
| 241 | + | |
| 242 | +<blockquote><tt> | |
| 243 | +fossil info merge-in:xyzzy:2022-03-01 | |
| 244 | +</tt></blockquote> | |
| 245 | + | |
| 246 | +to get informations about the most recent merge-in point on the branch | |
| 247 | +"xyzzy" that happened on or before March 1, 2022. | |
| 239 | 248 | |
| 240 | 249 | <h2 id="special">Special Tags</h2> |
| 241 | 250 | |
| 242 | 251 | The tag "tip" means the most recent check-in. The "tip" tag is practically |
| 243 | 252 | equivalent to the timestamp "9999-12-31". |
| 244 | 253 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -98,13 +98,13 @@ | |
| 98 | is not anything special: it is simply a sequence of check-ins that |
| 99 | share a common tag, so the same mechanism that resolves tag names |
| 100 | also resolves branch names. |
| 101 | |
| 102 | <a id="tagpfx"></a> |
| 103 | Note also that there can — in theory, if rarely in practice — be an ambiguity between tag names |
| 104 | and canonical names. Suppose, for example, you had a check-in with |
| 105 | the canonical name deed28aa99… and you |
| 106 | also happened to have tagged a different check-in with "deed2". If |
| 107 | you use the "deed2" name, does it choose the canonical name or the tag |
| 108 | name? In such cases, you can prefix the tag name with "tag:". |
| 109 | For example: |
| 110 | |
| @@ -183,12 +183,12 @@ | |
| 183 | |
| 184 | <blockquote> |
| 185 | http://fossil-scm.org/home/doc/<b>trunk</b>/www/index.wiki |
| 186 | </blockquote> |
| 187 | |
| 188 | The bold component of that URL is a check-in name. To see the stored |
| 189 | content of the Fossil website repository as of January 1, 2009, one has merely to change |
| 190 | the URL to the following: |
| 191 | |
| 192 | <blockquote> |
| 193 | http://fossil-scm.org/home/doc/<b>2009-01-01</b>/www/index.wiki |
| 194 | </blockquote> |
| @@ -202,13 +202,13 @@ | |
| 202 | A check-in name can also take the form of a tag or branch name followed by |
| 203 | a colon and then a timestamp. The combination means to take the most |
| 204 | recent check-in with the given tag or branch which is not more recent than |
| 205 | the timestamp. So, for example: |
| 206 | |
| 207 | <blockquote> |
| 208 | fossil update trunk:2010-07-01T14:30 |
| 209 | </blockquote> |
| 210 | |
| 211 | Would cause Fossil to update the working check-out to be the most recent |
| 212 | check-in on the trunk that is not more recent than 14:30 (UTC) on |
| 213 | July 1, 2010. |
| 214 | |
| @@ -218,13 +218,13 @@ | |
| 218 | last check-in on the parent branch prior to the beginning of the branch. |
| 219 | Such a label is useful, for example, in computing all diffs for a single |
| 220 | branch. The following example will show all changes in the hypothetical |
| 221 | branch "xyzzy": |
| 222 | |
| 223 | <blockquote> |
| 224 | fossil diff --from root:xyzzy --to xyzzy |
| 225 | </blockquote> |
| 226 | |
| 227 | <a id="merge-in"></a> |
| 228 | That doesn't do what you might expect after you merge the parent |
| 229 | branch's changes into the child branch: the above command will include |
| 230 | changes made on the parent branch as well. |
| @@ -234,10 +234,19 @@ | |
| 234 | the most recent merge-in point for that branch. |
| 235 | The resulting diff will then show only the changes in |
| 236 | the branch itself, omitting |
| 237 | any changes that have already been merged in from the parent branch. |
| 238 | |
| 239 | |
| 240 | <h2 id="special">Special Tags</h2> |
| 241 | |
| 242 | The tag "tip" means the most recent check-in. The "tip" tag is practically |
| 243 | equivalent to the timestamp "9999-12-31". |
| 244 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -98,13 +98,13 @@ | |
| 98 | is not anything special: it is simply a sequence of check-ins that |
| 99 | share a common tag, so the same mechanism that resolves tag names |
| 100 | also resolves branch names. |
| 101 | |
| 102 | <a id="tagpfx"></a> |
| 103 | Note also that there can — in theory, if rarely in practice — be an ambiguity |
| 104 | between tag names and canonical names. Suppose, for example, you had a |
| 105 | check-in with the canonical name deed28aa99… and you |
| 106 | also happened to have tagged a different check-in with "deed2". If |
| 107 | you use the "deed2" name, does it choose the canonical name or the tag |
| 108 | name? In such cases, you can prefix the tag name with "tag:". |
| 109 | For example: |
| 110 | |
| @@ -183,12 +183,12 @@ | |
| 183 | |
| 184 | <blockquote> |
| 185 | http://fossil-scm.org/home/doc/<b>trunk</b>/www/index.wiki |
| 186 | </blockquote> |
| 187 | |
| 188 | The bold component of that URL is a check-in name. To see the stored content |
| 189 | of the Fossil website repository as of January 1, 2009, one has merely to change |
| 190 | the URL to the following: |
| 191 | |
| 192 | <blockquote> |
| 193 | http://fossil-scm.org/home/doc/<b>2009-01-01</b>/www/index.wiki |
| 194 | </blockquote> |
| @@ -202,13 +202,13 @@ | |
| 202 | A check-in name can also take the form of a tag or branch name followed by |
| 203 | a colon and then a timestamp. The combination means to take the most |
| 204 | recent check-in with the given tag or branch which is not more recent than |
| 205 | the timestamp. So, for example: |
| 206 | |
| 207 | <blockquote><tt> |
| 208 | fossil update trunk:2010-07-01T14:30 |
| 209 | </tt></blockquote> |
| 210 | |
| 211 | Would cause Fossil to update the working check-out to be the most recent |
| 212 | check-in on the trunk that is not more recent than 14:30 (UTC) on |
| 213 | July 1, 2010. |
| 214 | |
| @@ -218,13 +218,13 @@ | |
| 218 | last check-in on the parent branch prior to the beginning of the branch. |
| 219 | Such a label is useful, for example, in computing all diffs for a single |
| 220 | branch. The following example will show all changes in the hypothetical |
| 221 | branch "xyzzy": |
| 222 | |
| 223 | <blockquote><tt> |
| 224 | fossil diff --from root:xyzzy --to xyzzy |
| 225 | </tt></blockquote> |
| 226 | |
| 227 | <a id="merge-in"></a> |
| 228 | That doesn't do what you might expect after you merge the parent |
| 229 | branch's changes into the child branch: the above command will include |
| 230 | changes made on the parent branch as well. |
| @@ -234,10 +234,19 @@ | |
| 234 | the most recent merge-in point for that branch. |
| 235 | The resulting diff will then show only the changes in |
| 236 | the branch itself, omitting |
| 237 | any changes that have already been merged in from the parent branch. |
| 238 | |
| 239 | The prefixes "<tt>root:</tt>" and "<tt>merge-in:</tt>" can be chained: one |
| 240 | can say for example |
| 241 | |
| 242 | <blockquote><tt> |
| 243 | fossil info merge-in:xyzzy:2022-03-01 |
| 244 | </tt></blockquote> |
| 245 | |
| 246 | to get informations about the most recent merge-in point on the branch |
| 247 | "xyzzy" that happened on or before March 1, 2022. |
| 248 | |
| 249 | <h2 id="special">Special Tags</h2> |
| 250 | |
| 251 | The tag "tip" means the most recent check-in. The "tip" tag is practically |
| 252 | equivalent to the timestamp "9999-12-31". |
| 253 |