[PATCH] Show an example of deleting commits with git-rebase.

[PATCH] Show an example of deleting commits with git-rebase.

[Shawn O. Pearce]

This particular use of git-rebase to remove a single commit or a
range of commits from the history of a branch recently came up on
the mailing list.  Documenting the example should help other users
arrive at the same solution on their own.

It also was not obvious to the newcomer that git-rebase is able to
accept any commit for --onto <newbase> and <upstream>.  We should
at least minimally document this, as much of the language in
git-rebase's manpage refers to 'branch' rather than 'committish'.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 Documentation/git-rebase.txt |   27 +++++++++++++++++++++++++--
 1 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 0cb9e1f..977f661 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -114,6 +114,27 @@ would result in:
 
 This is useful when topicB does not depend on topicA.
 
+A range of commits could also be removed with rebase.  If we have
+the following situation:
+
+------------
+    E---F---G---H---I---J  topicA
+------------
+
+then the command
+
+    git-rebase --onto topicA~5 topicA~2 topicA
+
+would result in the removal of commits F and G:
+
+------------
+    E---H'---I'---J'  topicA
+------------
+
+This is useful if F and G were flawed in some way, or should not be
+part of topicA.  Note that the argument to --onto and the <upstream>
+parameter can be any valid commit-ish.
+
 In case of conflict, git-rebase will stop at the first problematic commit
 and leave conflict markers in the tree.  You can use git diff to locate
 the markers (<<<<<<) and make edits to resolve the conflict.  For each
@@ -141,10 +162,12 @@ OPTIONS
 <newbase>::
 	Starting point at which to create the new commits. If the
 	--onto option is not specified, the starting point is
-	<upstream>.
+	<upstream>.  May be any valid commit, and not just an
+	existing branch name.
 
 <upstream>::
-	Upstream branch to compare against.
+	Upstream branch to compare against.  May be any valid commit,
+	not just an existing branch name.
 
 <branch>::
 	Working branch; defaults to HEAD.
-- 
1.5.0.rc3.58.g79812

Re: [PATCH] Show an example of deleting commits with git-rebase.

[Michael S. Tsirkin]

> Quoting Shawn O. Pearce <spearce@spearce.org>:
> Subject: [PATCH] Show an example of deleting commits with git-rebase.
> 
> This particular use of git-rebase to remove a single commit or a
> range of commits from the history of a branch recently came up on
> the mailing list.  Documenting the example should help other users
> arrive at the same solution on their own.
> 
> It also was not obvious to the newcomer that git-rebase is able to
> accept any commit for --onto <newbase> and <upstream>.  We should
> at least minimally document this, as much of the language in
> git-rebase's manpage refers to 'branch' rather than 'committish'.
> 
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
>  Documentation/git-rebase.txt |   27 +++++++++++++++++++++++++--
>  1 files changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 0cb9e1f..977f661 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -114,6 +114,27 @@ would result in:
>  
>  This is useful when topicB does not depend on topicA.
>  
> +A range of commits could also be removed with rebase.  If we have
> +the following situation:
> +
> +------------
> +    E---F---G---H---I---J  topicA
> +------------
> +
> +then the command
> +
> +    git-rebase --onto topicA~5 topicA~2 topicA
> +
> +would result in the removal of commits F and G:
> +
> +------------
> +    E---H'---I'---J'  topicA
> +------------
> +
> +This is useful if F and G were flawed in some way, or should not be
> +part of topicA.  Note that the argument to --onto and the <upstream>
> +parameter can be any valid commit-ish.
> +

Good clarification, a couple of comments:
- The use of <branch> is more confusing than useful in this case.
  You can always just do
	git reset --hard topicA
	git-rebase --onto topicA~5 topicA~2
  instead, correct?

- The use of ~ notation here is also more scary than clarifying.
   git-rebase --onto F H
  will be clearer I think.

-- 
MST

Re: [PATCH] Show an example of deleting commits with git-rebase.

[Jakub Narebski]

Michael S. Tsirkin wrote:
> Shawn O. Pearce <spearce@spearce.org> wrote:

>> Subject: [PATCH] Show an example of deleting commits with git-rebase.
>> 
>> +A range of commits could also be removed with rebase.  If we have
>> +the following situation:
>> +
>> +------------
>> +    E---F---G---H---I---J  topicA
>> +------------
>> +
>> +then the command
>> +
>> +    git-rebase --onto topicA~5 topicA~2 topicA
>> +
>> +would result in the removal of commits F and G:
>> +
>> +------------
>> +    E---H'---I'---J'  topicA
>> +------------
>> +
>> +This is useful if F and G were flawed in some way, or should not be
>> +part of topicA.  Note that the argument to --onto and the <upstream>
>> +parameter can be any valid commit-ish.
>> +
> 
> Good clarification, a couple of comments:
> - The use of <branch> is more confusing than useful in this case.
>   You can always just do
>       git reset --hard topicA
>       git rebase --onto topicA~5 topicA~2
>   instead, correct?

I disagree. In my opinion using of <branch> makes it more clear: which
branch we are rebasing, and range of commits moved.
 
> - The use of ~ notation here is also more scary than clarifying.
>    git rebase --onto F H
>   will be clearer I think.

I agree.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] Show an example of deleting commits with git-rebase.

[Andy Parkins]

On Wednesday 2007 February 07 10:16, Michael S. Tsirkin wrote:

> > +    git-rebase --onto topicA~5 topicA~2 topicA

> Good clarification, a couple of comments:
> - The use of <branch> is more confusing than useful in this case.
>   You can always just do
> 	git reset --hard topicA
> 	git-rebase --onto topicA~5 topicA~2
>   instead, correct?

Seems more dangerous to me.  If we're not on topicA now, then the reset would 
throw away our current branch; if we are on topicA then we don't need it 
(assuming the working directory is not dirty).  At least with the explicit 
specification of topicA as <branch> there is no risk that the user will find 
themselves with their master branch junked.

> - The use of ~ notation here is also more scary than clarifying.
>    git-rebase --onto F H
>   will be clearer I think.

While you're right that it is clearer; it also removes the practical example.  
In real life there is no easy name for F or H; they are just random hashes.  
topicA~5 will work in real life as well as the example.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com