On Tue, Feb 17, 2009 at 2:18 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Because it is designed to handle a lot more general case of fetching all > remote branches into your remote tracking branches with wildcard refspecs, > and most of the entries need to be marked with not-for-merge marker. If > you left only the for-merge branches, you would not have any sane way to > learn what refs were fetched after you said "git fetch" (and no, looking > at timestamp of files in .git/refs/remotes/origin/ is not a sensible > answer). We are talking past each other. I understand the not-for-merge marker, why git fetch puts it there, and how it is used by git pull. I was asking why "git merge FETCH_HEAD" is useful, and you gave an example of fetching a *single* branch using "git fetch <url> <branch>". But in that case, as you said, git fetch does *not* leave a "not-for-merge" marker, since only one branch was fetched. So then, why does "git merge FETCH_HEAD" bother to strip out a not-for-merge marker that wouldn't be there? I can only guess there is a use case where one fetches multiple branches and then uses "git merge FETCH_HEAD". j. -- 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
