git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] refuse to merge during a merge

From
Junio C Hamano <gitster@pobox.com>
Date
May 31, 2009, 19:36 UTC
Message-ID
<7vd49prrne.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20090531104359.GA19094@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
Show 8 quoted lines
> The following is an easy mistake to make for users coming from version
> control systems with an "update and commit"-style workflow.
>
>         1. git pull
>         2. resolve conflicts
>         3. git pull
>
> Step 3 overrides MERGE_HEAD, starting a new merge with dirty index.

I think the new condition that you added to stop the merge is more in line with the original intent of the check. We never wanted to check "do we still have unmerged entries?" but wanted to see "is another merge in progress?"; not checking MERGE_HEAD was a simple omission.

But I do not necessarily agree with the combined check nor with the new message. I think it would be more sensible to split the codepath like this:

	if (we see MERGE_HEAD)
		die("You have not concluded your merge (MERGE_HEAD exists).");
	if (the index is unmerged)
		die("You are in the middle of a conflicted merge (index unmerged).");

Then in a _later_ patch, you could try to be more helpful by paying more attention to the context. E.g.

	if (we see MERGE_HEAD) {
        	figure out what was attempted by looking at
                MERGE_MSG and other cues;
		die("You have not concluded your merge with %s.\n"
		    "Perhaps you would want 'git reset' to recover?"
                    that);
	}
	if (the index is unmerged)
		die("You are in the middle of a conflicted merge");

The point is that combining the checks makes it harder to later give more appropriate diagnosis and suggestion to the end user.

For example, "git merge" may learn "git merge --abort" like other commands that have "attempt, stop, let the user fix up to conclude" modes of operations (i.e. rebase and am), and we may suggest to use that to recover in the message, instead of 'git reset'. But that can only be used if we stopped because we saw MERGE_HEAD; you definitely do not want to suggest "git merge --abort" if the index is unmerged due to a conflicted rebase in progress.

Note that I am not suggesting you to blow this up to one large patch by adding fancier "what were we doing" logic; I am perfectly OK with the minimum "detect MERGE_HEAD and refuse". I am only saying that I am unhappy with the way two different error conditions are conflated.

Personally, I'd suggest not to give "you can do this to recover" message.
Previous: Clemens BuchacherNext: Clemens Buchacher
Message 10 of 11 in “refuse to merge during a merge”
  1. refuse to merge during a mergeClemens Buchacher, May 27, 2009
  2. Constantine PlotnikovMay 28, 2009
  3. John TapsellMay 28, 2009
  4. Clemens BuchacherMay 30, 2009
  5. Jakub NarebskiMay 30, 2009
  6. Thomas RastMay 30, 2009
  7. refuse to merge during a mergeClemens Buchacher, May 31, 2009
  8. John TapsellMay 31, 2009
  9. Clemens BuchacherMay 31, 2009
  10. Junio C HamanoMay 31, 2009
  11. refuse to merge during a mergeClemens Buchacher, Jun 1, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.