Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> writes: > >> Ah, I now see. I tried to keep the text intact as much as possible, and >> only split it into description and a note. Well, how about this then: > > Much better than your earlier patch, but I am not sure if the > updated one is that much better compared to the original. It's not intended to be much better. It is aimed at single simple target: get rid of git-pull from descriptions of operations of git-merge. I'd just remove those git-pull reference, the only one that is left after the patch, but it looks like git-merge needs an excuse to have fast-forward on by default, and that excuse is the common git-pull case. [I'd prefer 'git-merge --ff' were called from 'git-pull' and --no-ff be the default for git-merge, but that's not the case, so I left the reference to git-pull intact.] > > The pre- and post- state of this "how about this" patch essentially > say the same thing, and I suspect that the primary reason why you > think the post- state is easier to read is because you wrote it, > while the reason why I do not see much difference is because I > didn't write the updated one ;-). > > I do find "In this case, ... store the combined history" in the > original a bit awkward to read, but most of that awkardness is > inherited by the updated text. It may benefit from hinting why a > new commit is not needed a bit stronger. Here is my attempt: > > When the commit we are merging is a descendant of the current > HEAD, the history leading to the named commit can be, and by > default is, taken as the combined history of the two. Our > history is "fast forwarded" to their history by updating `HEAD` > along with the index to point at the named commit. > > This often happens when you are following along somebody else's > work via "git pull" without doing your own development. > > I think the awkwardness I felt in the original and your version is > gone from the above attempt, but I doubt that it is better over > either of them in any other way. This is entirely different matter, and should be a subject of another patch, if any. My patch meant to only address git-pull references, with as few changes as possible. -- Sergey