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

Re: git merge vs git commit

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 9, 2008, 17:34 UTC
Message-ID
<7vhc8p6x59.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<20080909165236.GA8850@flint.arm.linux.org.uk>
Russell King <rmk@arm.linux.org.uk> writes:
Show 8 quoted lines
> If there aren't any conflicts, you get a nice clean merge, resulting in:
> ...
> However, if you have a conflict that needs resolving, you fix it up as
> ...
> instead - an additional reference from commit 'K' back to commit 'A'
> which isn't present in the clean merge case.
>
> Is this intentional, or is it a bug?

I think some changes went into 1.6.0 around this area to (r)eject parents that are redundant. What happens when you use more recent git with the same example?

Previous: Russell KingNext: Miklos Vajna
Message 2 of 5 in “git merge vs git commit”
  1. Russell KingSep 9, 2008
  2. Junio C HamanoSep 9, 2008
  3. Miklos VajnaSep 9, 2008
  4. Junio C HamanoSep 9, 2008
  5. Matthieu MoySep 9, 2008

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.