>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
