Stefan Beller <[email protected]> writes:
> so I just run into this problem again (which happens to me maybe twice a
> week):
> I want to do a git operations, so I type "git " into my shell, and
> then I look around what
> exactly I want to do and usually I find it in the help text of a
> previous command such as
> You are currently reverting commit 383c14b.
> (fix conflicts and run "git revert --continue")
> (use "git revert --abort" to cancel the revert operation)
>
> then I copy the whole operation "git revert --abort" in this case and
> paste it to the shell
> and let go.
> The result looks like
> $ git git revert --abort
> git: 'git' is not a git command. See 'git --help'.
>
> Did you mean this?
> init
>
> I wonder if we want to make a "git" subcommand, which behaves exactly
> the same as git itself?
> Then "git git git status" would just return the same as "git status".
A few unrelated thoughts.
* Perhaps we should omit 'git' from these advice-texts? E.g.
use "revert --abort" to cancel
I dunno.
* While we bend over backwards to a certain degree to be helpful, I
somehow feel making "git git" a synonym to "git" is going too
far, akin to asking POSIX maintainers to define "act", "cta",
"atc", "tca", and "tac" all as synonyms to "cat" because you
often fat-finger when typing "cat" (yes, "tac" does something
else that is more useful, I know).
* You can help yourself with something like this, I suppose:
[alias]
git = "!sh -c 'exec git \"$@\"' -"
but I personally feel that it is too ugly to live as part of our
official suggestion, so please do not send a patch to add it as
a built-in alias ;-).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
