Junio C Hamano venit, vidit, dixit 10.03.2015 21:20:
> JFF stands for just for fun.
>
> This is not meant to give out a model answer and is known to be
> incomplete, but I was wondering if it would be a better direction to
> allow "-" as a stand-in for "@{-1}" everywhere we allow a branch
> name, losing workarounds at the surface level we have for checkout,
> merge and revert.
>
> The first three paths are to remove the surface workarounds that
> become unnecessary. The one in sha1_name.c is the central change.
>
> The change in revision.c is to allow a single "-" to be recognized
> as a potential revision name (without this change, what begins with
> "-" is either an option or an unknown option).
>
> So you could do things like "git reset - $path" but also things like
> "git log -" after switching out of a branch.
>
> What does not work are what needs further tweaking in revision.c
> parser. "git checkout master && git checkout next && git log -.."
> should show what next has on top of master but I didn't touch the
> range notation so it does not work, for example.
>
> builtin/checkout.c | 3 ---
> builtin/merge.c | 3 +--
> builtin/revert.c | 2 --
> revision.c | 2 +-
> sha1_name.c | 57 +++++++++++++++++++++++++++++++++---------------------
> 5 files changed, 37 insertions(+), 30 deletions(-)
Like it :)
It removes the special casing and makes a shorthand available
systematically. I'd say it's useful even without extending it to ranges.
Michae
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html