git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
* "Losing" MERGE_HEAD
@ 2019-05-31  4:16 Bryan Turner
  2019-05-31  6:03 ` Elijah Newren
  0 siblings, 1 reply; 2+ messages in thread
From: Bryan Turner @ 2019-05-31  4:16 UTC (permalink / raw)
  To: Git Users

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: "Losing" MERGE_HEAD
  2019-05-31  4:16 "Losing" MERGE_HEAD Bryan Turner
@ 2019-05-31  6:03 ` Elijah Newren
  0 siblings, 0 replies; 2+ messages in thread
From: Elijah Newren @ 2019-05-31  6:03 UTC (permalink / raw)
  To: Bryan Turner; +Cc: Git Users

On Thu, May 30, 2019 at 9:19 PM Bryan Turner <bturner@atlassian.com> wrote:
>
> 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

Discussed in detail recently starting at
https://public-inbox.org/git/CACsJy8Axa5WsLSjiscjnxVK6jQHkfs-gH959=YtUvQkWriAk5w@mail.gmail.com/

resulting in
https://public-inbox.org/git/20190329103919.15642-8-pclouds@gmail.com/
and
https://public-inbox.org/git/20190329103919.15642-24-pclouds@gmail.com/

I think we should still do the follow up for checkout, as mentioned at
https://public-inbox.org/git/CABPp-BHX1gRhTdurAwrPg60Hk-OuhbrEN=4zatx4OOUo-DkQvw@mail.gmail.com/

It's good to get extra feedback that this isn't just theoretical but
is causing people actual problems.  Do you want to take the time to
make the change I suggested in the last email above and propose it to
the list?  I think the main thing needed is just a good commit message
and getting feedback and thoughts from others; your description above
was well written and I'm busy on other things right now, so if you'd
like to tackle it, I'd appreciate it.  If not, I will hopefully
remember to get back to it eventually.

Hope that helps,
Elijah

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-05-31  6:03 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-31  4:16 "Losing" MERGE_HEAD Bryan Turner
2019-05-31  6:03 ` Elijah Newren

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	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/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

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

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git