{"thread":{"id":"25589","subject":"[RFC/PATCH 0/2] Documentation: kicking the \"reset --hard\" habit","startedAt":"2010-10-29T08:35:16Z","lastAt":"2010-11-05T14:39:34Z","messageCount":10,"participants":["Jonathan Nieder","Matthieu Moy","Junio C Hamano","Ævar Arnfjörð Bjarmason","J. Bruce Fields","Stephen Boyd","Drew Northup"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"154770","messageId":"20101029083516.GA26290@burratino","threadId":"25589","inReplyTo":null,"subject":"[RFC/PATCH 0/2] Documentation: kicking the \"reset --hard\" habit","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-29T08:35:16Z","receivedAt":"2010-10-29T08:35:16Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nKira on IRC reminded me that our introductory documentation does\nnot explain how to use the new reset --keep and --merge primitives.\n\nSadly, at least the user manual change suggested below is probably\nnot suitable, since reset --keep and --merge have not been around\nsince git 1.5.3 days.  Ideas for working around that and other\ncomments would be welcome.\n\nJonathan Nieder (2):\n  Documentation: suggest \"reset --merge\" more often\n  Documentation: suggest \"reset --keep\" more often\n\n Documentation/git-bisect-lk2009.txt               |    2 +-\n Documentation/git-bisect.txt                      |    2 +-\n Documentation/git-checkout.txt                    |    2 +-\n Documentation/git-merge.txt                       |    2 +-\n Documentation/git-rerere.txt                      |    2 +-\n Documentation/git-reset.txt                       |   13 ++++++-----\n Documentation/gitcore-tutorial.txt                |    6 ++--\n Documentation/gitworkflows.txt                    |    2 +-\n Documentation/howto/maintain-git.txt              |    4 +-\n Documentation/howto/separating-topic-branches.txt |    2 +-\n Documentation/user-manual.txt                     |   22 ++++++++++++++------\n 11 files changed, 34 insertions(+), 25 deletions(-)\n"},{"id":"154771","messageId":"20101029083836.GB26290@burratino","threadId":"25589","inReplyTo":"20101029083516.GA26290@burratino","subject":"[RFC/PATCH 1/2] Documentation: suggest \"reset --merge\" more often","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-29T08:38:36Z","receivedAt":"2010-10-29T08:38:36Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"With its new semantics, \"git reset --merge\" is more suitable for\nundoing a failed merge than \"git reset --hard\" is.  It is especially\nnice if you forget that you are in a merge and make a change or two:\n\n  git merge something-complicated\n  ... notice conflicts, walk away ...\n  vi foo.c\n  git commit; # fails because the index has unmerged entries\n  git reset --merge\n\nThe modern (post-1.7.0) semantics of git reset --merge ensure that\nthe changes to foo.c will be preserved by this sequence of commands,\nunless foo.c was one of the files with conflicts.\n\nSo in the spirit of ed4a6baa (Documentation: suggest `reset --merge`\nin How Merge Works section, 2010-01-23), recommend it in place of\n\"reset --hard\".\n\nOne caveat: for habitual adders-to-index, \"git reset --merge\" is\nno better than \"git reset --hard\" (though still no worse).\n\n  vi foo.c\n  git add -u\n  git diff --cached --check; # fails because conflict markers are present\n  git reset --merge; # equivalent to git reset --hard\n\nSigned-off-by: Jonathan Nieder <jrnieder@gmail.com>\n---\n Documentation/git-merge.txt   |    2 +-\n Documentation/git-reset.txt   |    9 +++++----\n Documentation/user-manual.txt |    9 ++++++++-\n 3 files changed, 14 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex 84043cc..498931b 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -213,7 +213,7 @@ After seeing a conflict, you can do two things:\n \n  * Decide not to merge.  The only clean-ups you need are to reset\n    the index file to the `HEAD` commit to reverse 2. and to clean\n-   up working tree changes made by 2. and 3.; `git-reset --hard` can\n+   up working tree changes made by 2. and 3.; `git reset --merge` can\n    be used for this.\n \n  * Resolve the conflicts.  Git will mark the conflicts in\ndiff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt\nindex fd72976..1d0d9e6 100644\n--- a/Documentation/git-reset.txt\n+++ b/Documentation/git-reset.txt\n@@ -179,7 +179,7 @@ $ git pull                         <1>\n Auto-merging nitfol\n CONFLICT (content): Merge conflict in nitfol\n Automatic merge failed; fix conflicts and then commit the result.\n-$ git reset --hard                 <2>\n+$ git reset --merge                <2>\n $ git pull . topic/branch          <3>\n Updating from 41223... to 13134...\n Fast-forward\n@@ -189,9 +189,10 @@ $ git reset --hard ORIG_HEAD       <4>\n <1> Try to update from the upstream resulted in a lot of\n conflicts; you were not ready to spend a lot of time merging\n right now, so you decide to do that later.\n-<2> \"pull\" has not made merge commit, so \"git reset --hard\"\n-which is a synonym for \"git reset --hard HEAD\" clears the mess\n-from the index file and the working tree.\n+<2> \"pull\" has not made merge commit, so \"git reset --merge\"\n+which is a synonym for \"git reset --merge HEAD\" clears the mess\n+from the index file and the working tree.  \"git reset --hard\"\n+would work as well.\n <3> Merge a topic branch into the current branch, which resulted\n in a fast-forward.\n <4> But you decided that the topic branch is not ready for public\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex fc56da6..9120ad5 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -1372,12 +1372,19 @@ Undoing a merge\n ---------------\n \n If you get stuck and decide to just give up and throw the whole mess\n-away, you can always return to the pre-merge state with\n+away, you can always return to the last commit's state with\n \n -------------------------------------------------\n $ git reset --hard HEAD\n -------------------------------------------------\n \n+If you have changes that should be preserved in files not touched by\n+the merge, instead use\n+\n+-------------------------------------------------\n+$ git reset --merge HEAD\n+-------------------------------------------------\n+\n Or, if you've already committed the merge that you want to throw away,\n \n -------------------------------------------------\n-- \n1.7.2.3.557.gab647.dirty\n"},{"id":"154772","messageId":"20101029083930.GC26290@burratino","threadId":"25589","inReplyTo":"20101029083516.GA26290@burratino","subject":"[RFC/PATCH 2/2] Documentation: suggest \"reset --keep\" more often","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-29T08:39:30Z","receivedAt":"2010-10-29T08:39:30Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Practically speaking, a \"reset --hard\" fulfills two purposes:\n\n 1. erase uncommitted changes (in the index and worktree)\n 2. checkout a different commit without changing which branch\n    HEAD is attached to\n\nThe relatively new \"git reset --keep\" command does (2) without\n(1), which makes it simpler to use for use cases that amount to\n\"rewind HEAD\".\n\nSigned-off-by: Jonathan Nieder <jrnieder@gmail.com>\n---\n Documentation/git-bisect-lk2009.txt               |    2 +-\n Documentation/git-bisect.txt                      |    2 +-\n Documentation/git-checkout.txt                    |    2 +-\n Documentation/git-rerere.txt                      |    2 +-\n Documentation/git-reset.txt                       |    4 ++--\n Documentation/gitcore-tutorial.txt                |    6 +++---\n Documentation/gitworkflows.txt                    |    2 +-\n Documentation/howto/maintain-git.txt              |    4 ++--\n Documentation/howto/separating-topic-branches.txt |    2 +-\n Documentation/user-manual.txt                     |   13 +++++++------\n 10 files changed, 20 insertions(+), 19 deletions(-)\n\ndiff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt\nindex 8a2ba37..b581da8 100644\n--- a/Documentation/git-bisect-lk2009.txt\n+++ b/Documentation/git-bisect-lk2009.txt\n@@ -1188,7 +1188,7 @@ should not forget to remove the patch once the testing is done before\n exiting from the script.\n \n (Note that instead of a patch you can use \"git cherry-pick BFC\" to\n-apply the fix, and in this case you should use \"git reset --hard\n+apply the fix, and in this case you should use \"git reset --keep\n HEAD^\" to revert the cherry-pick after testing and before returning\n from the script.)\n \ndiff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt\nindex c39d957..43582a8 100644\n--- a/Documentation/git-bisect.txt\n+++ b/Documentation/git-bisect.txt\n@@ -158,7 +158,7 @@ For example:\n $ git bisect good/bad\t\t\t# previous round was good or bad.\n Bisecting: 337 revisions left to test after this\n $ git bisect visualize\t\t\t# oops, that is uninteresting.\n-$ git reset --hard HEAD~3\t\t# try 3 revisions before what\n+$ git reset --keep HEAD~3\t\t# try 3 revisions before what\n \t\t\t\t\t# was suggested\n ------------\n \ndiff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt\nindex 22d3611..f92fe3f 100644\n--- a/Documentation/git-checkout.txt\n+++ b/Documentation/git-checkout.txt\n@@ -223,7 +223,7 @@ current branch and directly points at the commit named by the tag\n (`v2.6.18` in the example above).\n \n You can use all git commands while in this state.  You can use\n-`git reset --hard $othercommit` to further move around, for\n+`git reset --keep $othercommit` to further move around, for\n example.  You can make changes and create a new commit on top of\n a detached HEAD.  You can even create a merge by using `git\n merge $othercommit`.\ndiff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt\nindex db99d47..4ed4262 100644\n--- a/Documentation/git-rerere.txt\n+++ b/Documentation/git-rerere.txt\n@@ -132,7 +132,7 @@ top of the tip before the test merge:\n ------------\n \t$ git checkout topic\n \t$ git merge master\n-\t$ git reset --hard HEAD^ ;# rewind the test merge\n+\t$ git reset --keep HEAD^ ;# rewind the test merge\n \t$ ... work on both topic and master branches\n \t$ git checkout master\n \t$ git merge topic\ndiff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt\nindex 1d0d9e6..301419c 100644\n--- a/Documentation/git-reset.txt\n+++ b/Documentation/git-reset.txt\n@@ -148,7 +148,7 @@ Undo a commit, making it a topic branch::\n +\n ------------\n $ git branch topic/wip     <1>\n-$ git reset --hard HEAD~3  <2>\n+$ git reset --keep HEAD~3  <2>\n $ git checkout topic/wip   <3>\n ------------\n +\n@@ -163,7 +163,7 @@ Undo commits permanently::\n +\n ------------\n $ git commit ...\n-$ git reset --hard HEAD~3   <1>\n+$ git reset --keep HEAD~3   <1>\n ------------\n +\n <1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad\ndiff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt\nindex c27d086..14bdceb 100644\n--- a/Documentation/gitcore-tutorial.txt\n+++ b/Documentation/gitcore-tutorial.txt\n@@ -1182,9 +1182,9 @@ work.\" commit.\n \n ------------\n $ git checkout mybranch\n-$ git reset --hard master^2\n+$ git reset --keep master^2\n $ git checkout master\n-$ git reset --hard master^\n+$ git reset --keep master^\n ------------\n \n After rewinding, the commit structure should look like this:\n@@ -1660,7 +1660,7 @@ we just did and start over.  We would want to get the master\n branch before these two merges by resetting it to 'master~2':\n \n ------------\n-$ git reset --hard master~2\n+$ git reset --keep master~2\n ------------\n \n You can make sure `git show-branch` matches the state before\ndiff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt\nindex 1ef55ff..4a35a92 100644\n--- a/Documentation/gitworkflows.txt\n+++ b/Documentation/gitworkflows.txt\n@@ -301,7 +301,7 @@ topics on 'next':\n [caption=\"Recipe: \"]\n =====================================\n * `git checkout next`\n-* `git reset --hard master`\n+* `git reset --keep master`\n * `git merge ai/topic_in_next1`\n * `git merge ai/topic_in_next2`\n * ...\ndiff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt\nindex d527b30..f0c9e1b 100644\n--- a/Documentation/howto/maintain-git.txt\n+++ b/Documentation/howto/maintain-git.txt\n@@ -166,7 +166,7 @@ by doing the following:\n \n    then replace some parts with the new patch, and reapplying:\n \n-     $ git reset --hard ai/topic~$n\n+     $ git reset --keep ai/topic~$n\n      $ git am -3 -s 000*.txt\n \n    The full test suite is always run for 'maint' and 'master'\n@@ -212,7 +212,7 @@ by doing the following:\n  - Rebuild \"pu\" to merge the tips of topics not in 'next'.\n \n      $ git checkout pu\n-     $ git reset --hard next\n+     $ git reset --keep next\n      $ git merge ai/topic     ;# repeat for all remaining topics\n      $ make test\n \ndiff --git a/Documentation/howto/separating-topic-branches.txt b/Documentation/howto/separating-topic-branches.txt\nindex 6d3eb8e..b54826f 100644\n--- a/Documentation/howto/separating-topic-branches.txt\n+++ b/Documentation/howto/separating-topic-branches.txt\n@@ -80,7 +80,7 @@ The last diff better not to show anything other than cleanups\n for crufts.  Then I can finally clean things up:\n \n         $ git branch -D topic\n-        $ git reset --hard HEAD^ ;# nuke pretend merge\n+        $ git reset --keep HEAD^ ;# nuke pretend merge\n \n                                 \"topicB\"\n                o---o---o---o---o\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex 9120ad5..427717d 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -143,7 +143,7 @@ If you decide that you'd rather see version 2.6.17, you can modify\n the current branch to point at v2.6.17 instead, with\n \n ------------------------------------------------\n-$ git reset --hard v2.6.17\n+$ git reset --keep v2.6.17\n ------------------------------------------------\n \n Note that if the current branch head was your only reference to a\n@@ -531,13 +531,13 @@ says \"bisect\".  Choose a safe-looking commit nearby, note its commit\n id, and check it out with:\n \n -------------------------------------------------\n-$ git reset --hard fb47ddb2db...\n+$ git reset --keep fb47ddb2db...\n -------------------------------------------------\n \n then test, run \"bisect good\" or \"bisect bad\" as appropriate, and\n continue.\n \n-Instead of \"git bisect visualize\" and then \"git reset --hard\n+Instead of \"git bisect visualize\" and then \"git reset --keep\n fb47ddb2db...\", you might just want to tell git that you want to skip\n the current commit:\n \n@@ -1388,7 +1388,7 @@ $ git reset --merge HEAD\n Or, if you've already committed the merge that you want to throw away,\n \n -------------------------------------------------\n-$ git reset --hard ORIG_HEAD\n+$ git reset --keep ORIG_HEAD\n -------------------------------------------------\n \n However, this last command can be dangerous in some cases--never\n@@ -2011,7 +2011,8 @@ error: failed to push to 'ssh://yourserver.com/~you/proj.git'\n \n This can happen, for example, if you:\n \n-\t- use `git reset --hard` to remove already-published commits, or\n+\t- use `git reset --hard` or `git reset --keep` to remove\n+\t  already-published commits, or\n \t- use `git commit --amend` to replace already-published commits\n \t  (as in <<fixing-a-mistake-by-rewriting-history>>), or\n \t- use `git rebase` to rebase any already-published commits (as\n@@ -2585,7 +2586,7 @@ patches, then reset the state to before the patches:\n \n -------------------------------------------------\n $ git format-patch origin\n-$ git reset --hard origin\n+$ git reset --keep origin\n -------------------------------------------------\n \n Then modify, reorder, or eliminate patches as preferred before applying\n-- \n1.7.2.3.557.gab647.dirty\n"},{"id":"154821","messageId":"vpqzktwv3yx.fsf@bauges.imag.fr","threadId":"25589","inReplyTo":"20101029083516.GA26290@burratino","subject":"Re: [RFC/PATCH 0/2] Documentation: kicking the \"reset --hard\" habit","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-10-30T01:55:50Z","receivedAt":"2010-10-30T01:55:50Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Sadly, at least the user manual change suggested below is probably\n> not suitable, since reset --keep and --merge have not been around\n> since git 1.5.3 days.  Ideas for working around that and other\n> comments would be welcome.\n\nDo we really want to keep the user manual compatible with 1.5.3\nforever? It's nice to keep the user manual usable by slightly outdated\nGits, but 1.5.3 starts being really old, and older docs are still\navailable on the web (like\nhttp://www.kernel.org/pub/software/scm/git/docs/v1.5.3.8/git.html ).\n\ngit reset --merge appeared in Git 1.6.2, it sounds reasonable to say\nthe current user manual works from this version.\n\ngit reset --keep appeared in 1.7.1, hence far more recently. But I\nthink it can still be mentionned at least as an alternative to --hard.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"154862","messageId":"7vd3qr3tm8.fsf@alter.siamese.dyndns.org","threadId":"25589","inReplyTo":"vpqzktwv3yx.fsf@bauges.imag.fr","subject":"Re: [RFC/PATCH 0/2] Documentation: kicking the \"reset --hard\" habit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-10-31T03:53:51Z","receivedAt":"2010-10-31T03:53:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n>\n>> Sadly, at least the user manual change suggested below is probably\n>> not suitable, since reset --keep and --merge have not been around\n>> since git 1.5.3 days.  Ideas for working around that and other\n>> comments would be welcome.\n>\n> Do we really want to keep the user manual compatible with 1.5.3\n> forever? It's nice to keep the user manual usable by slightly outdated\n> Gits, but 1.5.3 starts being really old,...\n\n1.5.6 is more than 2 years old (June 18th, 2008), 1.5.3 is more than 3\nyears old (September 2nd, 2007).  In git timescale, they are becoming\nprehistoric.\n\nEven though the knowledge of the conceptual structure and the philosophy\nlearned with old versions like 1.5.X series would still apply to today's\ngit, at the UI level facing the end users, there are vast differences\n(some may call that improvements ;-) between them and today's git.\n\nI am tempted to say we should 1.5.X series behind, and name one that is\nstill relatively old like 1.6.3 (May 2009) or 1.6.4 (July 2009) the oldest\nvintage we currently recognise as a proper member of our family.\n\nWhat is the oldest version of git that is shipped with _current_ distros,\nby the way?\n"},{"id":"154891","messageId":"vpqaalujw69.fsf@bauges.imag.fr","threadId":"25589","inReplyTo":"7vd3qr3tm8.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] Documentation: kicking the \"reset --hard\" habit","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-10-31T14:04:14Z","receivedAt":"2010-10-31T14:04:14Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> What is the oldest version of git that is shipped with _current_ distros,\n> by the way?\n\nDebian stable has 1.5.6.5. Since there should be a Debian release\nwithin the next few months, that should be an upper bound on how old a\npackage can get in a release (well, unless for RedHat users maybe).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"154893","messageId":"AANLkTiknyZBeWY8Z14EF+uq_2feJxJniVBwpwjUHgdEF@mail.gmail.com","threadId":"25589","inReplyTo":"vpqzktwv3yx.fsf@bauges.imag.fr","subject":"Re: [RFC/PATCH 0/2] Documentation: kicking the \"reset --hard\" habit","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-10-31T17:25:20Z","receivedAt":"2010-10-31T17:25:20Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sat, Oct 30, 2010 at 01:55, Matthieu Moy\n<Matthieu.Moy@grenoble-inp.fr> wrote:\n\n>> Sadly, at least the user manual change suggested below is probably\n>> not suitable, since reset --keep and --merge have not been around\n>> since git 1.5.3 days.  Ideas for working around that and other\n>> comments would be welcome.\n>\n> Do we really want to keep the user manual compatible with 1.5.3\n> forever? It's nice to keep the user manual usable by slightly outdated\n> Gits, but 1.5.3 starts being really old, and older docs are still\n> available on the web (like\n> http://www.kernel.org/pub/software/scm/git/docs/v1.5.3.8/git.html ).\n\nI didn't know we even did this with our user manual. When I read\nmanuals for version X (e.g. PostgreSQL, Emacs or libc versions) I\nfully expect the features described to only work on the documented\nversion unless otherwise noted.\n"},{"id":"154940","messageId":"20101101200333.GG2340@fieldses.org","threadId":"25589","inReplyTo":"AANLkTiknyZBeWY8Z14EF+uq_2feJxJniVBwpwjUHgdEF@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] Documentation: kicking the \"reset --hard\" habit","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2010-11-01T20:03:33Z","receivedAt":"2010-11-01T20:03:33Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Oct 31, 2010 at 05:25:20PM +0000, Ævar Arnfjörð Bjarmason wrote:\n> On Sat, Oct 30, 2010 at 01:55, Matthieu Moy\n> <Matthieu.Moy@grenoble-inp.fr> wrote:\n> \n> >> Sadly, at least the user manual change suggested below is probably\n> >> not suitable, since reset --keep and --merge have not been around\n> >> since git 1.5.3 days.  Ideas for working around that and other\n> >> comments would be welcome.\n> >\n> > Do we really want to keep the user manual compatible with 1.5.3\n> > forever? It's nice to keep the user manual usable by slightly outdated\n> > Gits, but 1.5.3 starts being really old, and older docs are still\n> > available on the web (like\n> > http://www.kernel.org/pub/software/scm/git/docs/v1.5.3.8/git.html ).\n> \n> I didn't know we even did this with our user manual. When I read\n> manuals for version X (e.g. PostgreSQL, Emacs or libc versions) I\n> fully expect the features described to only work on the documented\n> version unless otherwise noted.\n\nYeah, previous versions of the user manual are still around if people\nneed them.  For a book or an independent website a wider range of\nversions would make more sense, but for documentation destributed with\nthe git source I think we can afford to be more aggressive.\n\nIf we think information about old versions is really important maybe\nsomeone could find a way to incorporate it in a way that doesn't intrude\ninto the main text too much (e.g. footnotes or an appendix.)\n\n--b.\n"},{"id":"155039","messageId":"4CD12C1C.2020507@gmail.com","threadId":"25589","inReplyTo":"20101029083836.GB26290@burratino","subject":"Re: [RFC/PATCH 1/2] Documentation: suggest \"reset --merge\" more often","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2010-11-03T09:32:12Z","receivedAt":"2010-11-03T09:32:12Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"On 10/29/10 01:38, Jonathan Nieder wrote:\n> With its new semantics, \"git reset --merge\" is more suitable for\n> undoing a failed merge than \"git reset --hard\" is.  It is especially\n> nice if you forget that you are in a merge and make a change or two:\n> \n>   git merge something-complicated\n>   ... notice conflicts, walk away ...\n>   vi foo.c\n>   git commit; # fails because the index has unmerged entries\n>   git reset --merge\n> \n> The modern (post-1.7.0) semantics of git reset --merge ensure that\n> the changes to foo.c will be preserved by this sequence of commands,\n> unless foo.c was one of the files with conflicts.\n> \n> So in the spirit of ed4a6baa (Documentation: suggest `reset --merge`\n> in How Merge Works section, 2010-01-23), recommend it in place of\n> \"reset --hard\".\n> \n> One caveat: for habitual adders-to-index, \"git reset --merge\" is\n> no better than \"git reset --hard\" (though still no worse).\n> \n>   vi foo.c\n>   git add -u\n>   git diff --cached --check; # fails because conflict markers are present\n>   git reset --merge; # equivalent to git reset --hard\n> \n\nWould it also be a good idea to fill in the hint in git status for the\nin_merge case with similar information?\n"},{"id":"155259","messageId":"1288967974.30670.13.camel@drew-northup.unet.maine.edu","threadId":"25589","inReplyTo":"vpqaalujw69.fsf@bauges.imag.fr","subject":"Oldest Currently Distributed Git {Re: [RFC/PATCH 0/2] Documentation: kicking the \"reset --hard\" habit}","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2010-11-05T14:39:34Z","receivedAt":"2010-11-05T14:39:34Z","isPatch":true,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Sun, 2010-10-31 at 15:04 +0100, Matthieu Moy wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> > What is the oldest version of git that is shipped with _current_ distros,\n> > by the way?\n> \n> Debian stable has 1.5.6.5. Since there should be a Debian release\n> within the next few months, that should be an upper bound on how old a\n> package can get in a release (well, unless for RedHat users maybe).\n> \n\nEPEL for RHEL5 is 1.5.5.6 (plus security/bugfix patches).\nRHEL5 itself doesn't have git (as if it did it wouldn't be in EPEL).\n\nWe await RHEL6--granted it will take a while to upgrade things to that\npoint after it comes out.\n\n-- \n-Drew Northup N1XIM\n   AKA RvnPhnx on OPN\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"}]}