Shawn Pearce <spearce@xxxxxxxxxxx> writes:
>> I personally think this is not an improvement, but rather a new
>> source of confusion. If the user wants a local merge, there is
>> 'git-merge'. And the distinction between the commands makes it
>> clear that local merge can merge any commits exactly because
>> they are available locally, while remote fetch+merge needs to
>> choose from what the remote side offers so not arbitrary commits
>> like foo@{3.days.ago} cannot be pulled.
>
> True. But you know you are doing a local merge with `git pull .`.
> So why should you be restricted from using the capabilities of a
> local merge just because the frontend you prefer to use is limited
> when its doing remote merges?
Personally I do not mind much about it because I happen to
understand what "git pull" is doing.
But I do mind having to spend time defending why we special case
only the dot form, when people with twisted minds start
complaining about inconsistencies among "git pull .git", "git
pull ." and "git pull $(pwd)". And no, I do not want to
introduce likes of "test `cd .git && pwd` == `cd $1 && pwd`" in
the code to make them behave consistently.
-
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