Vikrant Varma <> writes:

> On 02-05-2013 00:05, Junio C Hamano wrote:
>> If you step back a bit, you would notice two things.
>>   (1) Saying 'foo' when the user means 'origin/foo' is hardly the
>>       only (or even the most common) kind of mistake that the code
>>       you need to add to 'git merge' would encounter and could help
>>       the user with.
> Yes. I like your suggestion of using levenshtein.c, similar to what's
> been done in help.c:help_unknown_cmd. However, where do you draw the
> line? Do you also suggest 'remotes/origin/foo' for 'remotes/foo'?
> Also, which would you then prioritize for 'foo': 'fob' (this is local)
> or 'origin/foo'? In other words, what kind of mistakes are you looking
> to correct -  typos, or forgetful omissions, or both and something
> more?

This is your itch, so you get to choose what you would propose to
the list and have people tweak it ;-)

I personally think the first version should not use levenshtein _at
all_ (hence not solving my 'git checkout mastr'). I however want to
make sure the code is structured in such a way that allows other
people to build on top later.

> However, making the caller responsible for printing the suggestions
> may not be the best alternative.

That "responsibility" could be encapsulated in a separate helper
function the callers call instead of die().

The lower level machinery to come up with a suggested list of refs,
when the caller suspects that there is a typo in refs, is the same
across different commands, and it is insufficient to have a single
helper function that hardcodes "not something we can _MERGE_", and
copy the function to create many other helpers that do the same
thing but with different error messages.

You would need two layers, one that collects suggested list of refs,
and another that is directly called by the top-level caller that
takes the refname and the die message, and the latter would use the
former.  What I was showing was the lower level one, without the
higher level one that takes die message and a suspicious user input
(the higher level one would be trivial and do not need hand-holding
while designing).

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