Re: possible usability issue in rebase -i?

[Baz <brian.ewins@gmail.com>]

2009/10/27 Erik Faye-Lund <kusmabite@googlemail.com>:
> I recently came over a not-overly-helpful error in git rebase -i, when
> a line got wrapped by the editor so that a part of the commit-message
> was interpreted as a command:
>
> ---
> $ git rebase -i HEAD~20
> <edit file>
> Unknown command: .
> fatal: ambiguous argument 'Please fix this in the file C:/msysgit/git/.git/rebas
> e-merge/git-rebase-todo.': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
> fatal: Not a valid object name Please fix this in the file C:/msysgit/git/.git/r
> ebase-merge/git-rebase-todo.
> fatal: bad revision 'Please fix this in the file C:/msysgit/git/.git/rebase-merg
> e/git-rebase-todo.'
>
> $ git --version
> git version 1.6.5.1386.g43a7a.dirty
> ---
>
> In this particular case, the first character on the new line was '.',
> so the first line of the error message makes perfect sense, but the
> lines that followed the real error got me pretty confused. Perhaps
> this is something that could be cleaned away? I'd think that an
> unknown command always should be fatal, and not need to propagate
> further. But I might be wrong, as I'm not familiar with the inner
> workings of rebase -i.

I've got a somewhat related minor usability issue with rebase -i. I
accidentally typed something like 'git rebase -i -z' and got this
message:

error: unknown switch `z'
usage: git-rebase [-i] [options] [--] <upstream> [<branch>]
   or: git-rebase [-i] (--continue | --abort | --skip)

Available options are
    -v, --verbose         display a diffstat of what changed upstream
    --onto ...            rebase onto given branch instead of upstream
    -p, --preserve-merges
                          try to recreate merges instead of ignoring them
    -s, --strategy ...    use the given merge strategy
    -m, --merge           always used (no-op)
    -i, --interactive     always used (no-op)

The last two lines were the surprise. It suggested to me that '-i' and
'-m' were now the defaults for git-rebase - which of course they're
not. A user would not know that this is actually reporting the flags
that work for git-rebase--interactive, especially since that's not
what the command calls itself. I wasn't sure about the best approach
to fixing this - the only comparable commands that pass arbitrary
flags down to an exec'd program make it clear what program is going to
be called (usually git merge) and so interpreting errors is easier.

It seems the intent here was to signal that the flags are different
once a rebase is in progress, but this usage message is shown when
rebase -i -z is called in any state.

Cheers,
Brian
>
> --
> Erik "kusma" Faye-Lund
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>