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

[Fwd: Re: git merge vs git commit]

From
Gustaf Hendeby <hendeby@isy.liu.se>
Date
Sep 9, 2008, 17:58 UTC
Message-ID
<48C6B944.30900@isy.liu.se>
Sorry for the dup Junio, once again hit the wrong button when answering...
/Gustaf
-------- Original Message --------
Subject: Re: git merge vs git commit
Date: Tue, 09 Sep 2008 19:56:20 +0200
From: Gustaf Hendeby <hendeby@isy.liu.se>
To: Junio C Hamano <gitster@pobox.com>
References: <20080909165236.GA8850@flint.arm.linux.org.uk>
<7vhc8p6x59.fsf@gitster.siamese.dyndns.org>
On 2008-09-09 19:34, Junio C Hamano wrote:
Show 14 quoted lines
> Russell King <rmk@arm.linux.org.uk> writes:
> 
>> 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?

I get the same result with current next. Is this the expected result with this work, or an unwanted side effect?

/Gustaf
Message 1 of 1 in “[Fwd: Re: git merge vs git commit]”
  1. Gustaf HendebySep 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.