Re: replacing a bad commit

["Shawn O. Pearce" <spearce@spearce.org>]

Blu Corater <blu@daga.cl> wrote:
> I've got confused by the wording of the git-rebase man page. It says:
> 
>        <upstream>
>           Upstream branch to compare against

Hmm.  Yes, that manpage can be somewhat confusing.
 
> Which suggests to me that <upstream> must be a branch tip, and not a
> random commit, as seems to be the case (well, not random, but reachable
> from <branch> if I understand well). Also, the man page doesn't give any
> example of rebasing using a random commit as <upstream>, they all use
> branch tips which reinforced my wrong assumption.

The faster you abandon the idea of branch tip as argument, the
faster you will pickup the more advanced operations in Git.

Anytime we talk about a branch as input to a command, it can really
be any commit.  And anytime we talk about a commit or an object,
it can be expressed by using any of the operators discussed in
git-rev-parse's man page, which would include using a branch name
or an abbreviated (or full) SHA-1.

There are a limited number of commands which expect a branch name
(and only a branch name), as they modify that branch to contain a
new value.  Examples of these are relatively rare, but include:

  git-branch: the first argument is the name of the branch to create.
  git-checkout -b: again, the name of the branch to create.
  git-fetch: it can be asked to update local tracking branches.

-- 
Shawn.