{"thread":{"id":"22353","subject":"[PATCH v2 0/7] clarify 'git merge' documentation","startedAt":"2010-01-23T09:25:51Z","lastAt":"2010-02-12T14:15:11Z","messageCount":11,"participants":["Jonathan Nieder","Thomas Rast","Junio C Hamano","Raja R Harinath"],"isPatch":true,"patchVersion":2,"patchTotal":7},"messages":[{"id":"132459","messageId":"20100123092551.GA7571@progeny.tock","threadId":"22353","inReplyTo":null,"subject":"[PATCH v2 0/7] clarify 'git merge' documentation","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-01-23T09:25:51Z","receivedAt":"2010-01-23T09:25:51Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"For the previous round [1], I wrote something like this to clarify why\nmerging with dirty trees is safe. I hope it also makes git-merge.1\nmore useful for other purposes. I have not changed the warning in\nquestion, which belongs to a different topic.\n\nPatches 1-3 move some material towards the end of the 'merge' manual,\nto make the manpage easier to read straight through.\n\nPatch 4 adds a brief introduction for the reader who might not yet be\nfamiliar with branching and merging. I am especially interested in\nfeedback on this one. My writing tends not to be as clear as I would\nlike. Already some advice from Junio helped a great deal.\n\nPatches 5-7 organize the material on how the merge works into short,\ndigestible pieces. Patch 5 explains how a merge can abort without\ndoing anything, patch 6 the fast-forward merge, and patch 7 the true\nmerge, all from the point of view of what matters for the person\ninvoking ‘git merge’. Patch 7 is basically rewritten using Thomas’s\nadvice.\n\nThe patches are against doc-style/for-next of Thomas’s repo at\ngit://repo.or.cz/git/trast .\n\nThe advice from last round was very helpful. Apologies for taking so\nlong to respond to it.\n\nEnjoy,\nJonathan Nieder (7):\n Documentation: merge: move configuration section to end\n Documentation: suggest `reset --merge` in How Merge Works section\n Documentation: merge: move merge strategy list to end\n Documentation: merge: add an overview\n Documentation: emphasize when git merge terminates early\n Documentation: merge: add a section about fast-forward\n Documentation: simplify How Merge Works\n\n Documentation/git-merge.txt | 164 ++++++++++++++++++++++++-------------------\n 1 files changed, 92 insertions(+), 72 deletions(-)\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/136356/focus=136617\n"},{"id":"132460","messageId":"20100123092657.GB7571@progeny.tock","threadId":"22353","inReplyTo":"20100123092551.GA7571@progeny.tock","subject":"[PATCH 1/7] Documentation: merge: move configuration section to end","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-01-23T09:26:57Z","receivedAt":"2010-01-23T09:26:57Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Configuration and environment variables belong to the back matter\nof a manual page.\n\nSigned-off-by: Jonathan Nieder \nAcked-by: Petr Baudis \n---\n Documentation/git-merge.txt | 18 +++++++++---------\n 1 files changed, 9 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex c88bebe..6aa2bf3 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -48,15 +48,6 @@ include::merge-strategies.txt[]\n If you tried a merge which resulted in complex conflicts and\n want to start over, you can recover with 'git reset'.\n \n-CONFIGURATION\n--------------\n-include::merge-config.txt[]\n-\n-branch..mergeoptions::\n-\tSets default options for merging into branch . The syntax and\n-\tsupported options are the same as those of 'git merge', but option\n-\tvalues containing whitespace characters are currently not supported.\n-\n HOW MERGE WORKS\n ---------------\n \n@@ -249,6 +240,15 @@ changes into a merge commit. Small fixups like bumping\n release/version name would be acceptable.\n \n \n+CONFIGURATION\n+-------------\n+include::merge-config.txt[]\n+\n+branch..mergeoptions::\n+\tSets default options for merging into branch . The syntax and\n+\tsupported options are the same as those of 'git merge', but option\n+\tvalues containing whitespace characters are currently not supported.\n+\n SEE ALSO\n --------\n linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],\n-- \n1.6.6\n"},{"id":"132461","messageId":"20100123093118.GC7571@progeny.tock","threadId":"22353","inReplyTo":"20100123092551.GA7571@progeny.tock","subject":"[PATCH 2/7] Documentation: suggest `reset --merge` in How Merge Works section","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-01-23T09:31:19Z","receivedAt":"2010-01-23T09:31:19Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"The 'merge' manual suggests 'reset' to cancel a merge at the end\nof the Merge Strategies list. It is more logical to explain this\nright before explaining how merge conflicts work, so the daunted\nreader can have a way out when he or she needs it most.\n\nWhile at it, make the advice more dependable and self-contained\nby providing the --merge option.\n\nSigned-off-by: Jonathan Nieder \n---\nThis should make the reference to 'git reset' easier to find on\nsecond reading. Something like this ought to happen if we are\ngoing to move the Merge Strategies list down towards the end of\nthe man page.\n\n Documentation/git-merge.txt | 6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex 6aa2bf3..1fecedb 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -45,9 +45,6 @@ include::merge-options.txt[]\n include::merge-strategies.txt[]\n \n \n-If you tried a merge which resulted in complex conflicts and\n-want to start over, you can recover with 'git reset'.\n-\n HOW MERGE WORKS\n ---------------\n \n@@ -115,6 +112,9 @@ When there are conflicts, the following happens:\n same and the index entries for them stay as they were,\n i.e. matching `HEAD`.\n \n+If you tried a merge which resulted in complex conflicts and\n+want to start over, you can recover with `git reset --merge`.\n+\n HOW CONFLICTS ARE PRESENTED\n ---------------------------\n \n-- \n1.6.6\n"},{"id":"132462","messageId":"20100123093337.GD7571@progeny.tock","threadId":"22353","inReplyTo":"20100123092551.GA7571@progeny.tock","subject":"[PATCH 3/7] Documentation: merge: move merge strategy list to end","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-01-23T09:33:37Z","receivedAt":"2010-01-23T09:33:37Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"So the section layout changes as follows:\n\n NAME\n SYNOPSIS\n DESCRIPTION\n OPTIONS\n-MERGE STRATEGIES\n HOW MERGE WORKS\n HOW CONFLICTS ARE PRESENTED\n HOW TO RESOLVE CONFLICTS\n EXAMPLES\n+MERGE STRATEGIES\n CONFIGURATION\n SEE ALSO\n AUTHOR\n DOCUMENTATION\n GIT\n NOTES\n\nThe first-time user will care more about conflicts than about\nstrategies other than 'recursive'.\n\nOne of the examples uses -s ours, but I do not think this hinders\nreadability.\n\nSuggested-by: Thomas Rast \nSigned-off-by: Jonathan Nieder \n---\nThomas Rast wrote [1]:\n\n> While I agree with the general intent of deferring the strategies\n> further back, wouldn't it be better go all the way and instead put\n> them before (or even after, but one of them uses -s ours) \"EXAMPLES\"?\n> The average user will care more about conflicts than about strategies\n> other than 'recursive'.\n\nGood idea. Thanks!\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/136356/focus=136679\n\n Documentation/git-merge.txt | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex 1fecedb..83bf3e7 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -42,8 +42,6 @@ include::merge-options.txt[]\n \tYou need at least one . Specifying more than one\n \t obviously means you are trying an Octopus.\n \n-include::merge-strategies.txt[]\n-\n \n HOW MERGE WORKS\n ---------------\n@@ -240,6 +238,8 @@ changes into a merge commit. Small fixups like bumping\n release/version name would be acceptable.\n \n \n+include::merge-strategies.txt[]\n+\n CONFIGURATION\n -------------\n include::merge-config.txt[]\n-- \n1.6.6\n"},{"id":"132463","messageId":"20100123094246.GE7571@progeny.tock","threadId":"22353","inReplyTo":"20100123092551.GA7571@progeny.tock","subject":"[PATCH 4/7] Documentation: merge: add an overview","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-01-23T09:42:46Z","receivedAt":"2010-01-23T09:42:46Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"The reader unfamiliar with the concepts of branching and merging\nwould have been completely lost. Try to help him with a diagram.\n\nSigned-off-by: Jonathan Nieder \n---\nThe advice in [1] was very helpful. I fear I’ve made a mess of\nthe language even so. At least it does seem much clearer now.\n\nThoughts?\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/136356/focus=136629\n\n Documentation/git-merge.txt | 28 ++++++++++++++++++++++++++--\n 1 files changed, 26 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex 83bf3e7..a7a40c6 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -15,8 +15,32 @@ SYNOPSIS\n \n DESCRIPTION\n -----------\n-Merges the history specified by into HEAD, optionally using a\n-specific merge strategy.\n+Incorporates changes from the named commits (since the time their\n+histories diverged from the current branch) into the current\n+branch. This command is used by 'git pull' to incorporate changes\n+from another repository and can be used by hand to merge changes\n+from one branch into another.\n+\n+Assume the following history exists and the current branch is\n+\"`master`\":\n+\n+------------\n+ A---B---C topic\n+ /\n+ D---E---F---G master\n+------------\n+\n+Then \"`git merge topic`\" will replay the changes made on the\n+`topic` branch since it diverged from `master` (i.e., `E`) until\n+its current commit (`C`) on top of `master`, and record the result\n+in a new commit along with the names of the two parent commits and\n+a log message from the user describing the changes.\n+\n+------------\n+ A---B---C topic\n+ / \\\n+ D---E---F---G---H master\n+------------\n \n The second syntax ( `HEAD` ...) is supported for\n historical reasons. Do not use it from the command line or in\n-- \n1.6.6\n"},{"id":"132464","messageId":"20100123094417.GF7571@progeny.tock","threadId":"22353","inReplyTo":"20100123092551.GA7571@progeny.tock","subject":"[PATCH 5/7] Documentation: emphasize when git merge terminates early","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-01-23T09:44:17Z","receivedAt":"2010-01-23T09:44:17Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"A merge-based operation in git can fail in two ways: one that\nstops before touching anything, or one that goes ahead and\nresults in conflicts.\n\nAs the 'git merge' manual explains:\n\n| A merge is always between the current `HEAD` and one or more\n| commits (usually, branch head or tag), and the index file must\n| match the tree of `HEAD` commit (i.e. the contents of the last commit)\n| when it starts out.\n\nUnfortunately, the placement of this sentence makes it easy to\nskip over, and its formulation leaves the important point, that\nany other attempted merge will be gracefully aborted, unspoken.\n\nSo give this point its own section and expand upon it.\n\nProbably this could be simplified somewhat: after all, a change\nregistered in the index is just a special kind of local\nuncommited change, so the second added paragraph is only a\nspecial case of the first. It seemed more helpful to be explicit\nhere.\n\nInspired by .\n\nSigned-off-by: Jonathan Nieder \n---\nToo technical?\n\n Documentation/git-merge.txt | 31 +++++++++++++++++++++----------\n 1 files changed, 21 insertions(+), 10 deletions(-)\n\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex a7a40c6..3663d58 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -67,21 +67,32 @@ include::merge-options.txt[]\n \t obviously means you are trying an Octopus.\n \n \n+PRE-MERGE CHECKS\n+----------------\n+\n+Before applying outside changes, you should get your own work in\n+good shape and committed locally, so it will not be clobbered if\n+there are conflicts. See also linkgit:git-stash[1].\n+'git pull' and 'git merge' will stop without doing anything when\n+local uncommitted changes overlap with files that 'git pull'/'git\n+merge' may need to update.\n+\n+To avoid recording unrelated changes in the merge commit,\n+'git pull' and 'git merge' will also abort if there are any changes\n+registered in the index relative to the `HEAD` commit. (One\n+exception is when the changed index entries are in the state that\n+would result from the merge already.)\n+\n+If all named commits are already ancestors of `HEAD`, 'git merge'\n+will exit early with the message \"Already up-to-date.\"\n+\n HOW MERGE WORKS\n ---------------\n \n A merge is always between the current `HEAD` and one or more\n-commits (usually, branch head or tag), and the index file must\n-match the tree of `HEAD` commit (i.e. the contents of the last commit)\n-when it starts out. In other words, `git diff --cached HEAD` must\n-report no changes. (One exception is when the changed index\n-entries are already in the same state that would result from\n-the merge anyway.)\n-\n-Three kinds of merge can happen:\n+commits (usually a branch head or tag).\n \n-* The merged commit is already contained in `HEAD`. This is the\n- simplest case, called \"Already up-to-date.\"\n+Two kinds of merge can happen:\n \n * `HEAD` is already contained in the merged commit. This is the\n most common case especially when invoked from 'git pull':\n-- \n1.6.6\n"},{"id":"132465","messageId":"20100123094533.GG7571@progeny.tock","threadId":"22353","inReplyTo":"20100123092551.GA7571@progeny.tock","subject":"[PATCH 6/7] Documentation: merge: add a section about fast-forward","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-01-23T09:45:33Z","receivedAt":"2010-01-23T09:45:33Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Novices sometimes find the behavior of 'git merge' in the\nfast-forward case surprising. Describe it thoroughly.\n\nSigned-off-by: Jonathan Nieder \n---\nSometimes people ask on IRC.\n\n Documentation/git-merge.txt | 31 ++++++++++++++++++-------------\n 1 files changed, 18 insertions(+), 13 deletions(-)\n\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex 3663d58..0b86f2b 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -86,25 +86,30 @@ would result from the merge already.)\n If all named commits are already ancestors of `HEAD`, 'git merge'\n will exit early with the message \"Already up-to-date.\"\n \n+FAST-FORWARD MERGE\n+------------------\n+\n+Often the current branch head is an ancestor of the named commit.\n+This is the most common case especially when invoked from 'git\n+pull': you are tracking an upstream repository, you have committed\n+no local changes, and now you want to update to a newer upstream\n+revision. In this case, a new commit is not needed to store the\n+combined history; instead, the `HEAD` (along with the index) is\n+updated to point at the named commit, without creating an extra\n+merge commit.\n+\n+This behavior can be suppressed with the `--no-ff` option.\n+\n HOW MERGE WORKS\n ---------------\n \n A merge is always between the current `HEAD` and one or more\n commits (usually a branch head or tag).\n \n-Two kinds of merge can happen:\n-\n-* `HEAD` is already contained in the merged commit. This is the\n- most common case especially when invoked from 'git pull':\n- you are tracking an upstream repository, have committed no local\n- changes and now you want to update to a newer upstream revision.\n- Your `HEAD` (and the index) is updated to point at the merged\n- commit, without creating an extra merge commit. This is\n- called \"Fast-forward\".\n-\n-* Both the merged commit and `HEAD` are independent and must be\n- tied together by a merge commit that has both of them as its parents.\n- The rest of this section describes this \"True merge\" case.\n+Except in a fast-forward merge (see above), the branches to be\n+merged must be tied together by a merge commit that has both of them\n+as its parents.\n+The rest of this section describes this \"True merge\" case.\n \n The chosen merge strategy merges the two commits into a single\n new source tree.\n-- \n1.6.6\n"},{"id":"132466","messageId":"20100123094842.GH7571@progeny.tock","threadId":"22353","inReplyTo":"20100123092551.GA7571@progeny.tock","subject":"[PATCH 7/7] Documentation: simplify How Merge Works","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-01-23T09:48:42Z","receivedAt":"2010-01-23T09:48:42Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"The user most likely does not care about the exact order of\noperations because he cannot see it happening anyway. Instead,\ntry to explain what it means to merge two commits into a single\ntree.\n\nWhile at it:\n\n - Change the heading to TRUE MERGE. The entire manual page is\n about how merges work.\n\n - Document MERGE_HEAD. It is a useful feature, since it makes\n the parents of the intended merge commit easier to refer to.\n\n - Do not assume commits named on the 'git merge' command line come\n from another repository. For simplicity, the discussion of\n conflicts still does assume that there is only one and it is a\n branch head.\n\n - Do not start list items with `code`. Otherwise, a toolchain bug\n produces a line break in the generated nroff, resulting in odd\n extra space.\n\nSuggested-by: Thomas Rast \nSigned-off-by: Jonathan Nieder \n---\nThis is the end of series. Thanks for reading.\n\nThomas Rast wrote: [1]\n\n> So how about\n[...]\n> and then snip everything up to\n\nOh! Much better, thanks.\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/136356/focus=136629\n\n Documentation/git-merge.txt | 52 +++++++++++++-----------------------------\n 1 files changed, 16 insertions(+), 36 deletions(-)\n\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex 0b86f2b..7aa3f3f 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -100,52 +100,32 @@ merge commit.\n \n This behavior can be suppressed with the `--no-ff` option.\n \n-HOW MERGE WORKS\n----------------\n-\n-A merge is always between the current `HEAD` and one or more\n-commits (usually a branch head or tag).\n+TRUE MERGE\n+----------\n \n Except in a fast-forward merge (see above), the branches to be\n merged must be tied together by a merge commit that has both of them\n as its parents.\n-The rest of this section describes this \"True merge\" case.\n-\n-The chosen merge strategy merges the two commits into a single\n-new source tree.\n-When things merge cleanly, this is what happens:\n-\n-1. The results are updated both in the index file and in your\n- working tree;\n-2. Index file is written out as a tree;\n-3. The tree gets committed; and\n-4. The `HEAD` pointer gets advanced.\n \n-Because of 2., we require that the original state of the index\n-file matches exactly the current `HEAD` commit; otherwise we\n-will write out your local changes already registered in your\n-index file along with the merge result, which is not good.\n-Because 1. involves only those paths differing between your\n-branch and the branch you are merging\n-(which is typically a fraction of the whole tree), you can\n-have local modifications in your working tree as long as they do\n-not overlap with what the merge updates.\n+A merged version reconciling the changes from all branches to be\n+merged is committed, and your `HEAD`, index, and working tree are\n+updated to it. It is possible to have modifications in the working\n+tree as long as they do not overlap; the update will preserve them.\n \n-When there are conflicts, the following happens:\n+When it is not obvious how to reconcile the changes, the following\n+happens:\n \n-1. `HEAD` stays the same.\n-\n-2. Cleanly merged paths are updated both in the index file and\n+1. The `HEAD` pointer stays the same.\n+2. The `MERGE_HEAD` ref is set to point to the other branch head.\n+3. Paths that merged cleanly are updated both in the index file and\n in your working tree.\n-\n-3. For conflicting paths, the index file records up to three\n- versions; stage1 stores the version from the common ancestor,\n- stage2 from `HEAD`, and stage3 from the other branch (you\n+4. For conflicting paths, the index file records up to three\n+ versions: stage 1 stores the version from the common ancestor,\n+ stage 2 from `HEAD`, and stage 3 from `MERGE_HEAD` (you\n can inspect the stages with `git ls-files -u`). The working\n tree files contain the result of the \"merge\" program; i.e. 3-way\n- merge results with familiar conflict markers `<<< === >>>`.\n-\n-4. No other changes are done. In particular, the local\n+ merge results with familiar conflict markers `<<<` `===` `>>>`.\n+5. No other changes are made. In particular, the local\n modifications you had before you started merge will stay the\n same and the index entries for them stay as they were,\n i.e. matching `HEAD`.\n-- \n1.6.6\n"},{"id":"132536","messageId":"201001241425.07027.trast@student.ethz.ch","threadId":"22353","inReplyTo":"20100123092551.GA7571@progeny.tock","subject":"Re: [PATCH v2 0/7] clarify 'git merge' documentation","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-01-24T13:25:06Z","receivedAt":"2010-01-24T13:25:06Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"On Saturday 23 January 2010 10:25:51 Jonathan Nieder wrote:\n> Jonathan Nieder (7):\n> Documentation: merge: move configuration section to end\n> Documentation: suggest `reset --merge` in How Merge Works section\n> Documentation: merge: move merge strategy list to end\n> Documentation: merge: add an overview\n> Documentation: emphasize when git merge terminates early\n> Documentation: merge: add a section about fast-forward\n> Documentation: simplify How Merge Works\n[and in the other thread]\n> Jonathan Nieder (1):\n> Documentation: merge: use MERGE_HEAD to refer to the remote branch\n\nThanks Jonathan! Ack on all of them.\n\nI still had the following patches in my little documentation queue:\n\n Jonathan Nieder (2):\n Documentation: git gc packs refs by default now\n Documentation: tiny git config manual tweaks\n\n Thomas Rast (2):\n Documentation: show-files is now called git-ls-files\n Documentation: emphasise 'git shortlog' in its synopsis\n\nI actually forgot to post the last one, which I'll do shortly, but\nit's trivial so I just included it at the bottom.\n\nJunio, I gathered all of the above patches and pushed them again to\n\n git://repo.or.cz/git/trast.git doc-style/for-next\n\nIf that's ok and you merge it, I'll declare this the end of this\nlittle topic. Admittedly it grew a bit outside the original area of\nstyle fixes into a half-rewrite of git-merge(1).\n\n\n\n-- 8< --\nSubject: [PATCH] Documentation: emphasise 'git shortlog' in its synopsis\n\nThe accepted style in the SYNOPSIS section is for a command to be\n'emphasised'. Do so for the git-shortlog(1) manpage.\n\nSigned-off-by: Thomas Rast \n\ndiff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt\nindex ecf9e27..dfd4d0c 100644\n--- a/Documentation/git-shortlog.txt\n+++ b/Documentation/git-shortlog.txt\n@@ -9,7 +9,7 @@ SYNOPSIS\n --------\n [verse]\n git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w]\n-git shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[[,[,]]]] [...]\n+'git shortlog' [-n|--numbered] [-s|--summary] [-e|--email] [-w[[,[,]]]] [...]\n \n DESCRIPTION\n -----------\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"132556","messageId":"7v636r714n.fsf@alter.siamese.dyndns.org","threadId":"22353","inReplyTo":"201001241425.07027.trast@student.ethz.ch","subject":"Re: [PATCH v2 0/7] clarify 'git merge' documentation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-24T19:29:12Z","receivedAt":"2010-01-24T19:29:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks, pulled.\n"},{"id":"134345","messageId":"87zl3ey1zk.fsf@hariville.hurrynot.org","threadId":"22353","inReplyTo":"20100123094246.GE7571@progeny.tock","subject":"Re: [PATCH 4/7] Documentation: merge: add an overview","fromName":"Raja R Harinath","fromEmail":"harinath@hurrynot.org","sentAt":"2010-02-12T14:15:11Z","receivedAt":"2010-02-12T14:15:11Z","isPatch":true,"sender":{"key":"harinath@hurrynot.org","avatar":"https://avatars.githubusercontent.com/u/4610?v=4"},"body":"Hi,\n\nJonathan Nieder writes:\n[snip]\n> +Assume the following history exists and the current branch is\n> +\"`master`\":\n> +\n> +------------\n> + A---B---C topic\n> + /\n> + D---E---F---G master\n> +------------\n> +\n> +Then \"`git merge topic`\" will replay the changes made on the\n> +`topic` branch since it diverged from `master` (i.e., `E`) until\n> +its current commit (`C`) on top of `master`, and record the result\n> +in a new commit along with the names of the two parent commits and\n> +a log message from the user describing the changes.\n\nThe word 'replay' seems inappropriate for a description of 'merge'. To\nme 'replay' seems a synonym of 'rebase' (and IIRC tla has a 'replay'\ncommand that was similar to 'rebase' [1]).\n\n(Yeah, I know, I'm responding 3 weeks too late, and the patch is already\nin the tree.)\n\n- Hari\n\n[1] http://www.gnu.org/software/gnu-arch/tutorial/Introducing-replay-_002d_002d-An-Alternative-to-update.html\n"}]}