{"thread":{"id":"38278","subject":"[PATCH] subtree: fix AsciiDoc list item continuation","startedAt":"2015-01-04T10:54:47Z","lastAt":"2015-01-04T10:54:47Z","messageCount":1,"participants":["Steffen Prohaska"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"254276","messageId":"1420368887-10958-1-git-send-email-prohaska@zib.de","threadId":"38278","inReplyTo":null,"subject":"[PATCH] subtree: fix AsciiDoc list item continuation","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2015-01-04T10:54:47Z","receivedAt":"2015-01-04T10:54:47Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"List items must be continued with '+' (see [asciidoc]).\n\n[asciidoc] AsciiDoc user guide 17.7. List Item Continuation\n \n\nSigned-off-by: Steffen Prohaska \n---\n contrib/subtree/git-subtree.txt | 194 ++++++++++++++++++----------------------\n 1 file changed, 89 insertions(+), 105 deletions(-)\n\ndiff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt\nindex 8272100..54e4b4a 100644\n--- a/contrib/subtree/git-subtree.txt\n+++ b/contrib/subtree/git-subtree.txt\n@@ -81,12 +81,11 @@ merge::\n \tchanges into the latest . With '--squash',\n \tcreates only one commit that contains all the changes,\n \trather than merging in the entire history.\n-\n-\tIf you use '--squash', the merge direction doesn't\n-\talways have to be forward; you can use this command to\n-\tgo back in time from v2.5 to v2.4, for example. If your\n-\tmerge introduces a conflict, you can resolve it in the\n-\tusual ways.\n++\n+If you use '--squash', the merge direction doesn't always have to be\n+forward; you can use this command to go back in time from v2.5 to v2.4,\n+for example. If your merge introduces a conflict, you can resolve it in\n+the usual ways.\n \t\n pull::\n \tExactly like 'merge', but parallels 'git pull' in that\n@@ -107,21 +106,19 @@ split::\n \tcontents of at the root of the project instead\n \tof in a subdirectory. Thus, the newly created history\n \tis suitable for export as a separate git repository.\n-\t\n-\tAfter splitting successfully, a single commit id is\n-\tprinted to stdout. This corresponds to the HEAD of the\n-\tnewly created tree, which you can manipulate however you\n-\twant.\n-\t\n-\tRepeated splits of exactly the same history are\n-\tguaranteed to be identical (i.e. to produce the same\n-\tcommit ids). Because of this, if you add new commits\n-\tand then re-split, the new commits will be attached as\n-\tcommits on top of the history you generated last time,\n-\tso 'git merge' and friends will work as expected.\n-\t\n-\tNote that if you use '--squash' when you merge, you\n-\tshould usually not just '--rejoin' when you split.\n++\n+After splitting successfully, a single commit id is printed to stdout.\n+This corresponds to the HEAD of the newly created tree, which you can\n+manipulate however you want.\n++\n+Repeated splits of exactly the same history are guaranteed to be\n+identical (i.e. to produce the same commit ids). Because of this, if\n+you add new commits and then re-split, the new commits will be attached\n+as commits on top of the history you generated last time, so 'git merge'\n+and friends will work as expected.\n++\n+Note that if you use '--squash' when you merge, you should usually not\n+just '--rejoin' when you split.\n \n \n OPTIONS\n@@ -151,109 +148,96 @@ OPTIONS FOR add, merge, push, pull\n --squash::\n \tThis option is only valid for add, merge, push and pull\n \tcommands.\n-\n-\tInstead of merging the entire history from the subtree\n-\tproject, produce only a single commit that contains all\n-\tthe differences you want to merge, and then merge that\n-\tnew commit into your project.\n-\t\n-\tUsing this option helps to reduce log clutter. People\n-\trarely want to see every change that happened between\n-\tv1.0 and v1.1 of the library they're using, since none of the\n-\tinterim versions were ever included in their application.\n-\t\n-\tUsing '--squash' also helps avoid problems when the same\n-\tsubproject is included multiple times in the same\n-\tproject, or is removed and then re-added. In such a\n-\tcase, it doesn't make sense to combine the histories\n-\tanyway, since it's unclear which part of the history\n-\tbelongs to which subtree.\n-\t\n-\tFurthermore, with '--squash', you can switch back and\n-\tforth between different versions of a subtree, rather\n-\tthan strictly forward. 'git subtree merge --squash'\n-\talways adjusts the subtree to match the exactly\n-\tspecified commit, even if getting to that commit would\n-\trequire undoing some changes that were added earlier.\n-\t\n-\tWhether or not you use '--squash', changes made in your\n-\tlocal repository remain intact and can be later split\n-\tand send upstream to the subproject.\n++\n+Instead of merging the entire history from the subtree project, produce\n+only a single commit that contains all the differences you want to\n+merge, and then merge that new commit into your project.\n++\n+Using this option helps to reduce log clutter. People rarely want to see\n+every change that happened between v1.0 and v1.1 of the library they're\n+using, since none of the interim versions were ever included in their\n+application.\n++\n+Using '--squash' also helps avoid problems when the same subproject is\n+included multiple times in the same project, or is removed and then\n+re-added. In such a case, it doesn't make sense to combine the\n+histories anyway, since it's unclear which part of the history belongs\n+to which subtree.\n++\n+Furthermore, with '--squash', you can switch back and forth between\n+different versions of a subtree, rather than strictly forward. 'git\n+subtree merge --squash' always adjusts the subtree to match the exactly\n+specified commit, even if getting to that commit would require undoing\n+some changes that were added earlier.\n++\n+Whether or not you use '--squash', changes made in your local repository\n+remain intact and can be later split and send upstream to the\n+subproject.\n \n \n OPTIONS FOR split\n -----------------\n --annotate=::\n \tThis option is only valid for the split command.\n-\n-\tWhen generating synthetic history, add as a\n-\tprefix to each commit message. Since we're creating new\n-\tcommits with the same commit message, but possibly\n-\tdifferent content, from the original commits, this can help\n-\tto differentiate them and avoid confusion.\n-\t\n-\tWhenever you split, you need to use the same\n-\t, or else you don't have a guarantee that\n-\tthe new re-created history will be identical to the old\n-\tone. That will prevent merging from working correctly. \n-\tgit subtree tries to make it work anyway, particularly\n-\tif you use --rejoin, but it may not always be effective.\n++\n+When generating synthetic history, add as a prefix to each\n+commit message. Since we're creating new commits with the same commit\n+message, but possibly different content, from the original commits, this\n+can help to differentiate them and avoid confusion.\n++\n+Whenever you split, you need to use the same , or else you\n+don't have a guarantee that the new re-created history will be identical\n+to the old one. That will prevent merging from working correctly. git\n+subtree tries to make it work anyway, particularly if you use --rejoin,\n+but it may not always be effective.\n \n -b ::\n --branch=::\n \tThis option is only valid for the split command.\n-\n-\tAfter generating the synthetic history, create a new\n-\tbranch called that contains the new history. \n-\tThis is suitable for immediate pushing upstream. \n-\t must not already exist.\n++\n+After generating the synthetic history, create a new branch called\n+ that contains the new history. This is suitable for immediate\n+pushing upstream. must not already exist.\n \n --ignore-joins::\n \tThis option is only valid for the split command.\n-\n-\tIf you use '--rejoin', git subtree attempts to optimize\n-\tits history reconstruction to generate only the new\n-\tcommits since the last '--rejoin'. '--ignore-join'\n-\tdisables this behaviour, forcing it to regenerate the\n-\tentire history. In a large project, this can take a\n-\tlong time.\n++\n+If you use '--rejoin', git subtree attempts to optimize its history\n+reconstruction to generate only the new commits since the last\n+'--rejoin'. '--ignore-join' disables this behaviour, forcing it to\n+regenerate the entire history. In a large project, this can take a long\n+time.\n \n --onto=::\n \tThis option is only valid for the split command.\n-\n-\tIf your subtree was originally imported using something\n-\tother than git subtree, its history may not match what\n-\tgit subtree is expecting. In that case, you can specify\n-\tthe commit id that corresponds to the first\n-\trevision of the subproject's history that was imported\n-\tinto your project, and git subtree will attempt to build\n-\tits history from there.\n-\t\n-\tIf you used 'git subtree add', you should never need\n-\tthis option.\n++\n+If your subtree was originally imported using something other than git\n+subtree, its history may not match what git subtree is expecting. In\n+that case, you can specify the commit id that corresponds to the\n+first revision of the subproject's history that was imported into your\n+project, and git subtree will attempt to build its history from there.\n++\n+If you used 'git subtree add', you should never need this option.\n \n --rejoin::\n \tThis option is only valid for the split command.\n-\n-\tAfter splitting, merge the newly created synthetic\n-\thistory back into your main project. That way, future\n-\tsplits can search only the part of history that has\n-\tbeen added since the most recent --rejoin.\n-\t\n-\tIf your split commits end up merged into the upstream\n-\tsubproject, and then you want to get the latest upstream\n-\tversion, this will allow git's merge algorithm to more\n-\tintelligently avoid conflicts (since it knows these\n-\tsynthetic commits are already part of the upstream\n-\trepository).\n-\t\n-\tUnfortunately, using this option results in 'git log'\n-\tshowing an extra copy of every new commit that was\n-\tcreated (the original, and the synthetic one).\n-\t\n-\tIf you do all your merges with '--squash', don't use\n-\t'--rejoin' when you split, because you don't want the\n-\tsubproject's history to be part of your project anyway.\n++\n+After splitting, merge the newly created synthetic history back into\n+your main project. That way, future splits can search only the part of\n+history that has been added since the most recent --rejoin.\n++\n+If your split commits end up merged into the upstream subproject, and\n+then you want to get the latest upstream version, this will allow git's\n+merge algorithm to more intelligently avoid conflicts (since it knows\n+these synthetic commits are already part of the upstream repository).\n++\n+Unfortunately, using this option results in 'git log' showing an extra\n+copy of every new commit that was created (the original, and the\n+synthetic one).\n++\n+If you do all your merges with '--squash', don't use '--rejoin' when you\n+split, because you don't want the subproject's history to be part of\n+your project anyway.\n \n \n EXAMPLE 1. Add command\n-- \n2.2.1.217.gb07cdde\n"}]}