list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Bryan Turner <>
To: Git Users <>
Subject: "Losing" MERGE_HEAD
Date: Thu, 30 May 2019 21:16:56 -0700
Message-ID: <> (raw)

I was looking through the commit history in a repository I work in and
I found a place where someone had created a merge, but somewhere
between "git merge" and "git commit" the fact that it was a merge was
"lost". Instead they ended up with a really big commit that applied
all the changes from the merged-in branch.

A really easy way to reproduce this is:
git merge master #Assume this has conflicts, or use --no-commit
git checkout -b some-new-branch

When the checkout runs, MERGE_HEAD et al are deleted without any sort
of warning, but the uncommitted changes are not lost. If a user then
runs "git commit", and doesn't notice that there's no helpful "It
looks like you may be committing a merge", they'll create a new,
non-merge commit that essentially reapplies all the changes they
merged in.

I'm pretty familiar with Git and I make this mistake at least a few
times a year. So far I've always caught it during the commit, though.
Unfortunately, in this case, the bad "merge" wasn't noticed before it
made its way to master, so now it's there for good.

I'm not sure what there is to do about this. It's clear it's a
long-standing behavior. One approach might be to introduce a warning
when changing branches deletes MERGE_*. A different one might be to
fail to change branches without something like --force. I'm not sure
either is _better_ than the current behavior, but they're certainly
_clearer_. That said, perhaps this behavior is something someone
relies on.

Best regards,
Bryan Turner

             reply	other threads:[~2019-05-31  4:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-31  4:16 Bryan Turner [this message]
2019-05-31  6:03 ` Elijah Newren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

code repositories for the project(s) associated with this inbox:

AGPL code for this site: git clone