{"thread":{"id":"22871","subject":"failed to push","startedAt":"2010-03-01T21:15:20Z","lastAt":"2010-03-02T23:07:14Z","messageCount":10,"participants":["Bruce Korb","Jacob Helwig","Chris Packham","Erik Faye-Lund","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"135972","messageId":"4B8C2E68.3020507@gnu.org","threadId":"22871","inReplyTo":null,"subject":"failed to push","fromName":"Bruce Korb","fromEmail":"bkorb@gnu.org","sentAt":"2010-03-01T21:15:20Z","receivedAt":"2010-03-01T21:15:20Z","isPatch":false,"sender":{"key":"bkorb@gnu.org","avatar":null},"body":"Hi,\n\nThis message has no meaning at all.  I know it failed to push.\nI can tell from the comment \"[rejected]\".  It would be nice\nto know *WHY* it was rejected so I can fix the problem.\nHow do I determine the cause, please?  Thank you!!  Regards, Bruce\n\n$ git push\nTo ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen\n ! [rejected]        master -> master (non-fast forward)\nerror: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen'\n"},{"id":"135975","messageId":"4B8C303E.7050605@gmail.com","threadId":"22871","inReplyTo":"4B8C2E68.3020507@gnu.org","subject":"Re: failed to push","fromName":"Bruce Korb","fromEmail":"bruce.korb@gmail.com","sentAt":"2010-03-01T21:23:10Z","receivedAt":"2010-03-01T21:23:10Z","isPatch":false,"sender":{"key":"bruce.korb@gmail.com","avatar":"https://gravatar.com/avatar/86d91467dc7cc8466a9d133a7b93a5d21233052017c144c9a6f6f7e5110344d0?d=mp&s=160"},"body":"Bruce Korb wrote:\n> Hi,\n> \n> This message has no meaning at all.  I know it failed to push.\n> I can tell from the comment \"[rejected]\".  It would be nice\n> to know *WHY* it was rejected so I can fix the problem.\n> How do I determine the cause, please?  Thank you!!  Regards, Bruce\n> \n> $ git push\n> To ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen\n>  ! [rejected]        master -> master (non-fast forward)\n> error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen'\n> \n\nA little follow up context:\n\nI used the \"git gui citool\".  I saw a button to allow an amendment to a\nprevious checkin.  That seemed most appropriate, so I did that.  I had\npreviously pushed the commit to the sourceforge repository, so my guess\nwas that pushing would amend the checkin at sourceforge, too.  Nope.\nWon't let me push.  Won't tell me why, either.  Now what?  Thanks.\n"},{"id":"135976","messageId":"2793902788222999372@unknownmsgid","threadId":"22871","inReplyTo":"4B8C2E68.3020507@gnu.org","subject":"Re: failed to push","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2010-03-01T21:27:03Z","receivedAt":"2010-03-01T21:27:03Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Mar 1, 2010, at 13:15, Bruce Korb <bkorb@gnu.org> wrote:\n\n> Hi,\n>\n> This message has no meaning at all.  I know it failed to push.\n> I can tell from the comment \"[rejected]\".  It would be nice\n> to know *WHY* it was rejected so I can fix the problem.\n> How do I determine the cause, please?  Thank you!!  Regards, Bruce\n>\n> $ git push\n> To ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen\n> ! [rejected]        master -> master (non-fast forward)\n> error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net\n> /gitroot/autogen/autogen'\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n\nIt tells you right there at the end of the rejected line. The push\nwould have resulted in a non-fast-forward update of the branch.\n\nTo \"fix\" this, you need the current commit pointed to by the branch as\none of the ancestors of the commits you're trying to push.\n"},{"id":"135978","messageId":"a038bef51003011342j3d761d0cmd96d8641f96ed15@mail.gmail.com","threadId":"22871","inReplyTo":"4B8C303E.7050605@gmail.com","subject":"Re: failed to push","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2010-03-01T21:42:49Z","receivedAt":"2010-03-01T21:42:49Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Hi,\n\nOn Mon, Mar 1, 2010 at 1:23 PM, Bruce Korb <bruce.korb@gmail.com> wrote:\n> Bruce Korb wrote:\n>> Hi,\n>>\n>> This message has no meaning at all.  I know it failed to push.\n>> I can tell from the comment \"[rejected]\".  It would be nice\n>> to know *WHY* it was rejected so I can fix the problem.\n>> How do I determine the cause, please?  Thank you!!  Regards, Bruce\n>>\n>> $ git push\n>> To ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen\n>>  ! [rejected]        master -> master (non-fast forward)\n>> error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen'\n>>\n\nThis basically means that the push you have attempted is not a simple\nfast forward. This basically means that the commit your work is based\non is not present in the remote or that there have been other pushes\nto the remote and you need to pull them into your repository to handle\nany merging.\n\n>\n> A little follow up context:\n>\n> I used the \"git gui citool\".  I saw a button to allow an amendment to a\n> previous checkin.  That seemed most appropriate, so I did that.  I had\n> previously pushed the commit to the sourceforge repository, so my guess\n> was that pushing would amend the checkin at sourceforge, too.  Nope.\n> Won't let me push.  Won't tell me why, either.  Now what?  Thanks.\n> --\n\nOK that kind of sheds some light. I take it you've just switch from a\ncentralized VCS?\n\nIn a DVCS like git all commits happen locally, the only time commits\nare sent to the remote repo are when you've pushed so 'git commit\n--amend' or 'git gui' with the amend box ticked only makes the change\nlocally it won't implicitly figure out that a commit has been pushed\nout into the ether. One rule of thumb with git (I think it applies to\nmost DVCSes) is not to amend a commit that has been pushed for this\nvery reason. Strictly speaking all commits are immutable, when you\namend a commit you actually create a whole new commit and your old one\nis marked for garbage collection (if nothing else is based off it).\n\nIn terms of recovering from your present situation I'd try the\nfollowing (Disclaimer: maybe you shouldn't try these based solely on\nmy advice. I'm still learning too)\n\n  git pull\n  <resolve merge issue, 'git mergetool' is your friend>\n  git push\n\n  I think this will basically sort things out but you may need to hand\nhold a few things through a merge depending on how different the 2\ncommits are.\n\n - or -\n\n  git push -f\n\n  If you're the only one using that repository its probably fine but\nthis could cause problems for others if they've cloned the repo before\nyour amended commit.\n"},{"id":"135985","messageId":"4B8C38E5.7090305@gnu.org","threadId":"22871","inReplyTo":"a038bef51003011342j3d761d0cmd96d8641f96ed15@mail.gmail.com","subject":"Re: failed to push","fromName":"Bruce Korb","fromEmail":"bkorb@gnu.org","sentAt":"2010-03-01T22:00:05Z","receivedAt":"2010-03-01T22:00:05Z","isPatch":false,"sender":{"key":"bkorb@gnu.org","avatar":null},"body":"Hi,\n\nThank you-all for your replies.\n\nChris Packham wrote:\n>>> To ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen\n>>>  ! [rejected]        master -> master (non-fast forward)\n>>> error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen'\n\nCF:\n> It tells you right there at the end of the rejected line. The push\n> would have resulted in a non-fast-forward update of the branch.\n\n\"non-fast forward\" is not very helpful either.\n\n> This basically means that the push you have attempted is not a simple\n> fast forward. This basically means that the commit your work is based\n> on is not present in the remote or that there have been other pushes\n> to the remote and you need to pull them into your repository to handle\n> any merging.\n\nSince the sequence was:\n  git commit\n  git push\n  <more editing>\n  git commit --amend\n  git push\n\nthe neophyte (me) is not going to know that this produces an un-pulled\ndelta.\n\n> OK that kind of sheds some light. I take it you've just switch from a\n> centralized VCS?\n\n\"just switched\"?  No, I've been using BitKeeper for four years\nand just recently converted my open source stuff to GIT.  GIT\nis harder to work with.\n\n> In a DVCS like git all commits happen locally, the only time commits\n> are sent to the remote repo are when you've pushed so 'git commit\n> --amend' or 'git gui' with the amend box ticked only makes the change\n> locally it won't implicitly figure out that a commit has been pushed\n> out into the ether. One rule of thumb with git (I think it applies to\n> most DVCSes) is not to amend a commit that has been pushed for this\n> very reason.\n\nThen please be kind enough to put a *CAUTION* button next to\nthe amend button and have it bring up something that gives you\na little warning.  GIT *could* have been written in a way that\ncauses the remote repo to become synced with my local repo,\nbut apparently it was not and there was not adequate warning.\n\n> Strictly speaking all commits are immutable, when you\n> amend a commit you actually create a whole new commit and your old one\n> is marked for garbage collection (if nothing else is based off it).\n> \n> In terms of recovering from your present situation I'd try the\n> following (Disclaimer: maybe you shouldn't try these based solely on\n> my advice. I'm still learning too)\n> \n>   git pull\n>   <resolve merge issue, 'git mergetool' is your friend>\n>   git push\n> \n>   I think this will basically sort things out but you may need to hand\n> hold a few things through a merge depending on how different the 2\n> commits are.\n\nI will be trying this procedure momentarily.  Meanwhile, since I am\nthe only person on the planet authorized to commit to the public repo:\n\n>  - or -\n> \n>   git push -f\n\nThis fails with the same \"non-fast forward\" rejection message.  :(\n"},{"id":"135986","messageId":"4B8C39E2.2050904@gnu.org","threadId":"22871","inReplyTo":"4B8C38E5.7090305@gnu.org","subject":"Re: SUCCESS -- failed to push","fromName":"Bruce Korb","fromEmail":"bkorb@gnu.org","sentAt":"2010-03-01T22:04:18Z","receivedAt":"2010-03-01T22:04:18Z","isPatch":false,"sender":{"key":"bkorb@gnu.org","avatar":null},"body":"Bruce Korb wrote:\n>> In terms of recovering from your present situation I'd try the\n>> following (Disclaimer: maybe you shouldn't try these based solely on\n>> my advice. I'm still learning too)\n>>\n>>   git pull\n>>   <resolve merge issue, 'git mergetool' is your friend>\n>>   git push\n>>\n>>   I think this will basically sort things out but you may need to hand\n>> hold a few things through a merge depending on how different the 2\n>> commits are.\n> \n> I will be trying this procedure momentarily.\n\nThere were no resolution issues.  \"git pull ; git push\" was sufficient.\nThank you all for your help!  Regards, Bruce\n"},{"id":"136012","messageId":"40aa078e1003020344v5316dad4h5a53ea59ea9f0758@mail.gmail.com","threadId":"22871","inReplyTo":"4B8C38E5.7090305@gnu.org","subject":"Re: failed to push","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-03-02T11:44:26Z","receivedAt":"2010-03-02T11:44:26Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, Mar 1, 2010 at 11:00 PM, Bruce Korb <bkorb@gnu.org> wrote:\n> Hi,\n>\n> Thank you-all for your replies.\n>\n> Chris Packham wrote:\n>>>> To ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen\n>>>>  ! [rejected]        master -> master (non-fast forward)\n>>>> error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen'\n>\n> CF:\n>> It tells you right there at the end of the rejected line. The push\n>> would have resulted in a non-fast-forward update of the branch.\n>\n> \"non-fast forward\" is not very helpful either.\n>\n\nHow so? \"git help glossary\" gives you a description of what a\nfast-forward is. In my installed copy, it's spelled without a dash,\nthough. But that's a minor nit, I still found it easily.\n\n>> This basically means that the push you have attempted is not a simple\n>> fast forward. This basically means that the commit your work is based\n>> on is not present in the remote or that there have been other pushes\n>> to the remote and you need to pull them into your repository to handle\n>> any merging.\n>\n> Since the sequence was:\n>  git commit\n>  git push\n>  <more editing>\n>  git commit --amend\n>  git push\n>\n> the neophyte (me) is not going to know that this produces an un-pulled\n> delta.\n>\n\n\"git help commit\" gives a warning about this when documenting --amend,\nand links to the full description in the rebase-documentation.\n\n>> In a DVCS like git all commits happen locally, the only time commits\n>> are sent to the remote repo are when you've pushed so 'git commit\n>> --amend' or 'git gui' with the amend box ticked only makes the change\n>> locally it won't implicitly figure out that a commit has been pushed\n>> out into the ether. One rule of thumb with git (I think it applies to\n>> most DVCSes) is not to amend a commit that has been pushed for this\n>> very reason.\n>\n> Then please be kind enough to put a *CAUTION* button next to\n> the amend button and have it bring up something that gives you\n> a little warning.\n\nThat sounds to me like a good idea. Care enough to make a patch.\n\n> GIT *could* have been written in a way that\n> causes the remote repo to become synced with my local repo,\n> but apparently it was not and there was not adequate warning.\n>\n\nThat would have caused problems for anyone who cloned. But yes,\ngit-gui might benefit from a warning here.\n\n>>  - or -\n>>\n>>   git push -f\n>\n> This fails with the same \"non-fast forward\" rejection message.  :(\n\nI've seen this on sourceforge as well, it seems they have some extra\nchecks (hooks?) to disallow pushing rebased branches. The best thing\nwould be not to rewrite it. But if you INSIST, what worked for me was\nto delete the branch and then re-pushing it. Something like this \"git\npush remote-name :branch-name && git push remote-name branch-name\"\n\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"136033","messageId":"m3tysylexh.fsf@localhost.localdomain","threadId":"22871","inReplyTo":"4B8C38E5.7090305@gnu.org","subject":"Re: failed to push","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-03-02T19:09:15Z","receivedAt":"2010-03-02T19:09:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Bruce Korb <bkorb@gnu.org> writes:\n> Chris Packham wrote:\n> >>> To ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen\n> >>>  ! [rejected]        master -> master (non-fast forward)\n> >>> error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen'\n> \n> CF:\n> > It tells you right there at the end of the rejected line. The push\n> > would have resulted in a non-fast-forward update of the branch.\n> \n> \"non-fast forward\" is not very helpful either.\n\nIt is part of git jargon, and can be found in gitglossary.\n \n> > This basically means that the push you have attempted is not a simple\n> > fast forward. This basically means that the commit your work is based\n> > on is not present in the remote or that there have been other pushes\n> > to the remote and you need to pull them into your repository to handle\n> > any merging.\n> \n> Since the sequence was:\n>   git commit\n>   git push\n>   <more editing>\n>   git commit --amend\n>   git push\n> \n> the neophyte (me) is not going to know that this produces an un-pulled\n> delta.\n\nWell, all of us old gitters know: 1) that you should not change\npublished (pushed) history, 2) that commits are immutable, and 3) that\namending a commit generates new commit with correction and therefore\nchanges history.\n\nIt is true that git documentation (\"Git User's Manual\", \"Git Community\nBook\", \"Pro Git\") can be lacking... unfortunately by the time somebody\nis knowledgeable enough to write git documentaions, he/she is usally\nused to git way of doing things, and the documentation might not be\nnewbie-friendly.\n \n> > In a DVCS like git all commits happen locally, the only time commits\n> > are sent to the remote repo are when you've pushed so 'git commit\n> > --amend' or 'git gui' with the amend box ticked only makes the change\n> > locally it won't implicitly figure out that a commit has been pushed\n> > out into the ether. One rule of thumb with git (I think it applies to\n> > most DVCSes) is not to amend a commit that has been pushed for this\n> > very reason.\n> \n> Then please be kind enough to put a *CAUTION* button next to\n> the amend button and have it bring up something that gives you\n> a little warning.  GIT *could* have been written in a way that\n> causes the remote repo to become synced with my local repo,\n> but apparently it was not and there was not adequate warning.\n\nWhat git-gui (and other git interaces) could do is to check if there\nis indicator that the part of history you want to change (via amending\na commit, or via [interactive] rebase) is published.  On the other\nhand you probably would not want for git to access network to check it\nbefore history-rewriting commands...\n \n> > Strictly speaking all commits are immutable, when you\n> > amend a commit you actually create a whole new commit and your old one\n> > is marked for garbage collection (if nothing else is based off it).\n> > \n> > In terms of recovering from your present situation I'd try the\n> > following (Disclaimer: maybe you shouldn't try these based solely on\n> > my advice. I'm still learning too)\n> > \n> >   git pull\n> >   <resolve merge issue, 'git mergetool' is your friend>\n> >   git push\n> > \n> >   I think this will basically sort things out but you may need to hand\n> > hold a few things through a merge depending on how different the 2\n> > commits are.\n> \n> I will be trying this procedure momentarily.  Meanwhile, since I am\n> the only person on the planet authorized to commit to the public repo:\n> \n> >  - or -\n> > \n> >   git push -f\n> \n> This fails with the same \"non-fast forward\" rejection message.  :(\n\nWhether you are able to force pushing non fast-forward changes depends\non configuration on remote side (receive.denyNonFastForwards), and on\nthe update / pre-receive hooks which can also forbid forcing non\nfasf-forward changes.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"136041","messageId":"a038bef51003021336g3ab0b4f6vba2738a18a92dd36@mail.gmail.com","threadId":"22871","inReplyTo":"m3tysylexh.fsf@localhost.localdomain","subject":"Re: failed to push","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2010-03-02T21:36:47Z","receivedAt":"2010-03-02T21:36:47Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Tue, Mar 2, 2010 at 11:09 AM, Jakub Narebski <jnareb@gmail.com> wrote:\n\n> Well, all of us old gitters know: 1) that you should not change\n> published (pushed) history, 2) that commits are immutable, and 3) that\n> amending a commit generates new commit with correction and therefore\n> changes history.\n>\n> It is true that git documentation (\"Git User's Manual\", \"Git Community\n> Book\", \"Pro Git\") can be lacking... unfortunately by the time somebody\n> is knowledgeable enough to write git documentaions, he/she is usally\n> used to git way of doing things, and the documentation might not be\n> newbie-friendly.\n\nI thought I smelt an easy documentation patch but the current help for\ngit commit --amend seems to cover it\n\n\"You should understand the implications of rewriting history if you\namend a commit that has already been published\"\n\nThese sections [1],[2] of the git community book could probably do\nwith a note on the consequences or re-writing history. I'll see if I\ncan figure out how to submit a change.\n\n[1] http://book.git-scm.com/4_undoing_in_git_-_reset,_checkout_and_revert.html\n[2] http://book.git-scm.com/5_modifying_your_history.html\n\n>Bruce Korb <bkorb@gnu.org> writes:\n>> Then please be kind enough to put a *CAUTION* button next to\n>> the amend button and have it bring up something that gives you\n>> a little warning.  GIT *could* have been written in a way that\n>> causes the remote repo to become synced with my local repo,\n>> but apparently it was not and there was not adequate warning.\n\nShouldn't be too hard to repeat the warning from git help commit. Just\nnot sure of what the least intrusive way to do it is (plus my tcl-fu\nis weak).\n"},{"id":"136044","messageId":"1267571234-13565-1-git-send-email-judge.packham@gmail.com","threadId":"22871","inReplyTo":"a038bef51003021336g3ab0b4f6vba2738a18a92dd36@mail.gmail.com","subject":"[gitbook PATCH] add notes on re-writing history","fromName":"Chris Packham","fromEmail":"cp.packham@gmail.com","sentAt":"2010-03-02T23:07:14Z","receivedAt":"2010-03-02T23:07:14Z","isPatch":true,"sender":{"key":"cp.packham@gmail.com","avatar":null},"body":"Add a note on the consequences of re-writing a repositories history in\n\"Undoing in Git - Reset, Checkout and Revert/Fixing a mistake by\nmodifying a commit\" and \"Modifying your History\".\n---\nI didn't sucessfully get the ruby gems installed on openSUSE 11.2 (problems\ninstalling ultraviolet) so if someone who does have a working environment could\nhave a look and maybe do a bit of polishing that would be helpful.\n\n .../0_ Redoing_Git_Reset_and_Revert.markdown       |    6 +++++-\n .../0_Changing_History.markdown                    |   20 ++++++++++++++++++--\n 2 files changed, 23 insertions(+), 3 deletions(-)\n\ndiff --git a/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown b/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown\nindex b37245d..8b876f2 100644\n--- a/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown\t\n+++ b/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown\t\n@@ -43,7 +43,11 @@ fundamentally different ways to fix the problem:\n     never do this if you have already made the history public;\n     git does not normally expect the \"history\" of a project to\n     change, and cannot correctly perform repeated merges from\n-    a branch that has had its history changed.\n+    a branch that has had its history changed. If you do re-write\n+    a repositories history anyone else who has cloned the\n+    repository will need manually correct the problem on their\n+    clone see the \"RECOVERING FROM UPSTREAM REBASE\" section\n+    in linkgit:git-rebase[1].\n \n #### Fixing a mistake with a new commit ####\n \ndiff --git a/text/25_Changing_Your_History/0_Changing_History.markdown b/text/25_Changing_Your_History/0_Changing_History.markdown\nindex b569f46..160c838 100644\n--- a/text/25_Changing_Your_History/0_Changing_History.markdown\n+++ b/text/25_Changing_Your_History/0_Changing_History.markdown\n@@ -1,6 +1,22 @@\n ## Modifying your History ##\n \n-Interactive rebasing is a good way to modify individual commits.\n+There are several ways to re-write the history of a repository. All of\n+these can cause problems for commits that have already been pushed to a\n+remote repository. If you do re-write a repositories history anyone else\n+who has cloned the repository will need manually correct the problem on\n+their clone see the \"RECOVERING FROM UPSTREAM REBASE\" section in\n+linkgit:git-rebase[1].\n \n-linkgit:git-filter-branch[1] is a good way to edit commits en masse.\n+The simplest method is to use \"git commit --amend\" to modify the last commit.\n+This is useful to correct a commit message, or make a simple update to a\n+commit before pushing.\n+\n+Interactive rebasing is a good way to modify multiple commits. Commits can\n+be combined by squashing, changed by editing or removed entirely.\n+\n+linkgit:git-filter-branch[1] is a good way to edit commits en masse. This is\n+useful where a whole component needs to be removed from a project. For\n+example removing a subsystem which is licenced under an incompatible\n+opensource licence. Or it can be used to alter the commit authorship without\n+changing the code.\n \n-- \n1.7.0.1\n"}]}