[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