Michał Kiedrowicz [off-list ref] writes:
This happens when git merge is run to merge multiple commits that are
descendants of current HEAD (or are HEAD).
I am reasonably sure you meant ancestors here.
to origin/master but accidentaly we called (while being on master):
$ git merge master origin/master
I am very tempted to throw this into "don't do it then" category.
Junio C Hamano [off-list ref] wrote:
Michał Kiedrowicz [off-list ref] writes:
quoted
This happens when git merge is run to merge multiple commits that are
descendants of current HEAD (or are HEAD).
I am reasonably sure you meant ancestors here.
I meant: ... to merge commits whose parent, grand-parent or
grand-grand-...-parent is HEAD. Commits to which HEAD may be
fast-forwarded.
quoted
to origin/master but accidentaly we called (while being on master):
$ git merge master origin/master
I am very tempted to throw this into "don't do it then" category.
I'm all for it. This is not a thing I would want to be doing. At
no time I would call this "a serious bug that needs fixing right
now". Except that I still think this behavior is not correct. git-merge
should not create commits that even aren't merges (they have single
parrent) and have exactly the same tree as its parent, and give it a
message "merge". Isn't this against the normal behavior of Git:
forwarding if possible and refusing to create commits that don't change
any file?