Philip Oakley <> writes:
> Be clearer that the --fixup/--squash options can take any of the
> gitrevisions methods of specifying a commit, not just a 'hash'.
> Signed-off-by: Philip Oakley <>
> ---
> ...
> @@ -81,15 +81,15 @@ OPTIONS
>  --fixup=<commit>::
>       Construct a commit message for use with `rebase --autosquash`.
>       The commit message will be the subject line from the specified
> -     commit with a prefix of "fixup! ".  See linkgit:git-rebase[1]
> -     for details.
> +     commit revision with a prefix of "fixup! ".  See linkgit:git-rebase[1]
> +     and linkgit:gitrevisions[7] for details.

The same comment applies to the other hunk, but rephrasing "commit"
with "commit revision" (the latter is not even in the glossary) does
not make it clearer at all.  Especially when discussing rebases and
anything that rewrites commits, it can easily be mistaken as if you
are talking about v2 of the commit by fixing up the original, but
that is not the impression you want to give.

"The specified commit" is clear enough.  It may be debatable if we
want to talk about "how" to specify the commit, though.  I think the
use of "commit" in an angle-bracket-pair in the label for the
section, i.e. "--fixup=<commit>", has been considered to be clear
enough to tell that you can use usual extended SHA-1 syntax to
specify the commit you want to talk about, but if so, that is not
limited to this entry, and I do not think this description or the
other one for the "--squash" option are particularly worse than
those for the "-c" and "-C" options.  The description for "-c" does
say "Take an existing commit object", but that's like "the specified
commit" used here.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to