{"thread":{"id":"6697","subject":"[PATCH] Show an example of deleting commits with git-rebase.","startedAt":"2007-02-05T20:21:06Z","lastAt":"2007-02-07T12:11:57Z","messageCount":4,"participants":["Shawn O. Pearce","Michael S. Tsirkin","Jakub Narebski","Andy Parkins"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"33659","messageId":"20070205202106.GA8755@spearce.org","threadId":"6697","inReplyTo":null,"subject":"[PATCH] Show an example of deleting commits with git-rebase.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-05T20:21:06Z","receivedAt":"2007-02-05T20:21:06Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"This particular use of git-rebase to remove a single commit or a\nrange of commits from the history of a branch recently came up on\nthe mailing list.  Documenting the example should help other users\narrive at the same solution on their own.\n\nIt also was not obvious to the newcomer that git-rebase is able to\naccept any commit for --onto <newbase> and <upstream>.  We should\nat least minimally document this, as much of the language in\ngit-rebase's manpage refers to 'branch' rather than 'committish'.\n\nSigned-off-by: Shawn O. Pearce <spearce@spearce.org>\n---\n Documentation/git-rebase.txt |   27 +++++++++++++++++++++++++--\n 1 files changed, 25 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 0cb9e1f..977f661 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -114,6 +114,27 @@ would result in:\n \n This is useful when topicB does not depend on topicA.\n \n+A range of commits could also be removed with rebase.  If we have\n+the following situation:\n+\n+------------\n+    E---F---G---H---I---J  topicA\n+------------\n+\n+then the command\n+\n+    git-rebase --onto topicA~5 topicA~2 topicA\n+\n+would result in the removal of commits F and G:\n+\n+------------\n+    E---H'---I'---J'  topicA\n+------------\n+\n+This is useful if F and G were flawed in some way, or should not be\n+part of topicA.  Note that the argument to --onto and the <upstream>\n+parameter can be any valid commit-ish.\n+\n In case of conflict, git-rebase will stop at the first problematic commit\n and leave conflict markers in the tree.  You can use git diff to locate\n the markers (<<<<<<) and make edits to resolve the conflict.  For each\n@@ -141,10 +162,12 @@ OPTIONS\n <newbase>::\n \tStarting point at which to create the new commits. If the\n \t--onto option is not specified, the starting point is\n-\t<upstream>.\n+\t<upstream>.  May be any valid commit, and not just an\n+\texisting branch name.\n \n <upstream>::\n-\tUpstream branch to compare against.\n+\tUpstream branch to compare against.  May be any valid commit,\n+\tnot just an existing branch name.\n \n <branch>::\n \tWorking branch; defaults to HEAD.\n-- \n1.5.0.rc3.58.g79812\n"},{"id":"33789","messageId":"20070207101624.GC20290@mellanox.co.il","threadId":"6697","inReplyTo":"20070205202106.GA8755@spearce.org","subject":"Re: [PATCH] Show an example of deleting commits with git-rebase.","fromName":"Michael S. Tsirkin","fromEmail":"mst@mellanox.co.il","sentAt":"2007-02-07T10:16:24Z","receivedAt":"2007-02-07T10:16:24Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting Shawn O. Pearce <spearce@spearce.org>:\n> Subject: [PATCH] Show an example of deleting commits with git-rebase.\n> \n> This particular use of git-rebase to remove a single commit or a\n> range of commits from the history of a branch recently came up on\n> the mailing list.  Documenting the example should help other users\n> arrive at the same solution on their own.\n> \n> It also was not obvious to the newcomer that git-rebase is able to\n> accept any commit for --onto <newbase> and <upstream>.  We should\n> at least minimally document this, as much of the language in\n> git-rebase's manpage refers to 'branch' rather than 'committish'.\n> \n> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>\n> ---\n>  Documentation/git-rebase.txt |   27 +++++++++++++++++++++++++--\n>  1 files changed, 25 insertions(+), 2 deletions(-)\n> \n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index 0cb9e1f..977f661 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -114,6 +114,27 @@ would result in:\n>  \n>  This is useful when topicB does not depend on topicA.\n>  \n> +A range of commits could also be removed with rebase.  If we have\n> +the following situation:\n> +\n> +------------\n> +    E---F---G---H---I---J  topicA\n> +------------\n> +\n> +then the command\n> +\n> +    git-rebase --onto topicA~5 topicA~2 topicA\n> +\n> +would result in the removal of commits F and G:\n> +\n> +------------\n> +    E---H'---I'---J'  topicA\n> +------------\n> +\n> +This is useful if F and G were flawed in some way, or should not be\n> +part of topicA.  Note that the argument to --onto and the <upstream>\n> +parameter can be any valid commit-ish.\n> +\n\nGood clarification, a couple of comments:\n- The use of <branch> is more confusing than useful in this case.\n  You can always just do\n\tgit reset --hard topicA\n\tgit-rebase --onto topicA~5 topicA~2\n  instead, correct?\n\n- The use of ~ notation here is also more scary than clarifying.\n   git-rebase --onto F H\n  will be clearer I think.\n\n-- \nMST\n"},{"id":"33790","messageId":"eqc9c7$9lr$1@sea.gmane.org","threadId":"6697","inReplyTo":"20070207101624.GC20290@mellanox.co.il","subject":"Re: [PATCH] Show an example of deleting commits with git-rebase.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-07T10:25:41Z","receivedAt":"2007-02-07T10:25:41Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michael S. Tsirkin wrote:\n> Shawn O. Pearce <spearce@spearce.org> wrote:\n\n>> Subject: [PATCH] Show an example of deleting commits with git-rebase.\n>> \n>> +A range of commits could also be removed with rebase.  If we have\n>> +the following situation:\n>> +\n>> +------------\n>> +    E---F---G---H---I---J  topicA\n>> +------------\n>> +\n>> +then the command\n>> +\n>> +    git-rebase --onto topicA~5 topicA~2 topicA\n>> +\n>> +would result in the removal of commits F and G:\n>> +\n>> +------------\n>> +    E---H'---I'---J'  topicA\n>> +------------\n>> +\n>> +This is useful if F and G were flawed in some way, or should not be\n>> +part of topicA.  Note that the argument to --onto and the <upstream>\n>> +parameter can be any valid commit-ish.\n>> +\n> \n> Good clarification, a couple of comments:\n> - The use of <branch> is more confusing than useful in this case.\n>   You can always just do\n>       git reset --hard topicA\n>       git rebase --onto topicA~5 topicA~2\n>   instead, correct?\n\nI disagree. In my opinion using of <branch> makes it more clear: which\nbranch we are rebasing, and range of commits moved.\n \n> - The use of ~ notation here is also more scary than clarifying.\n>    git rebase --onto F H\n>   will be clearer I think.\n\nI agree.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33798","messageId":"200702071211.58890.andyparkins@gmail.com","threadId":"6697","inReplyTo":"20070207101624.GC20290@mellanox.co.il","subject":"Re: [PATCH] Show an example of deleting commits with git-rebase.","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-07T12:11:57Z","receivedAt":"2007-02-07T12:11:57Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 February 07 10:16, Michael S. Tsirkin wrote:\n\n> > +    git-rebase --onto topicA~5 topicA~2 topicA\n\n> Good clarification, a couple of comments:\n> - The use of <branch> is more confusing than useful in this case.\n>   You can always just do\n> \tgit reset --hard topicA\n> \tgit-rebase --onto topicA~5 topicA~2\n>   instead, correct?\n\nSeems more dangerous to me.  If we're not on topicA now, then the reset would \nthrow away our current branch; if we are on topicA then we don't need it \n(assuming the working directory is not dirty).  At least with the explicit \nspecification of topicA as <branch> there is no risk that the user will find \nthemselves with their master branch junked.\n\n> - The use of ~ notation here is also more scary than clarifying.\n>    git-rebase --onto F H\n>   will be clearer I think.\n\nWhile you're right that it is clearer; it also removes the practical example.  \nIn real life there is no easy name for F or H; they are just random hashes.  \ntopicA~5 will work in real life as well as the example.\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"}]}