Re: Pull without fetch

[Damien Robert <damien.olivier.robert@gmail.com>]

From Junio C Hamano, Mon 08 Apr 2019 at 10:34:07 (+0900) :
> In that simpler world, what you are trying to do would have been:

> 	git fetch
> 	# did I get anything worth integrating?
> 	git merge FETCH_HEAD

Indeed.

> That obviously would not work for those with "pull.rebase", and I do
> not think it makes much sense to teach "git rebase" the same trick
> to read FETCH_HEAD as "git merge" does in the above sequence.

Yes, it could learn to read the first branch not marked as not-for-merge,
but I agree this would be more confusing since it would introduce another
special handling of FETCH_HEAD, different from `merge` (which handle *all*
branches not marked as not-for-merge) and the other reference parsing
mechanisms (which simply look at the first branch in FETCh_HEAD).

> Others may have a better idea, but I do not immediately see any
> solution better than inventing a new option to "git pull".

Indeed, I was wondering if I was missing something since this is something
I do often (granted in practice it's not too hard to type `git merge` or
`git rebase` after the fetch for a branch; but when handling a lot of
branches at once I prefer to automatize this somewhat, and when I find
myself writing a script that needs to read branch.<name>.rebase values I am
left wondering if this would not be better to be directly supported in `git
pull` directly).


> Another and better option that may be harder to arrange is to make
> sure that a no-op "git fetch" incurs very low cost.  If you did so,
> "git fetch && git pull" would perform just like your "git fetch &&
> git pull --no-fetch", and we won't need a new option at all.

I am not sure I understand what a no-op `git fetch` means exactly.
In the "git fetch; <review changes>; git pull" scenario,
after I do the real `git fetch` and want to merge/rebase the changes, how
would I prevent `git pull` to pull new commits that were pushed in between?

-- 
Damien Robert