Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:47

Shawn Pearce [off-list ref] writes:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help