From: Junio C Hamano <gitster@pobox.com>
To: Miklos Vajna <vmiklos@frugalware.org>
Cc: Paolo Bonzini <bonzini@gnu.org>, Jeff King <peff@peff.net>,
git@vger.kernel.org
Subject: Re: [PATCH 1/2] merge: fix numerus bugs around "trivial merge" area
Date: Sat, 23 Aug 2008 18:58:37 -0700 [thread overview]
Message-ID: <7vtzdbuqb6.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <7vfxovy06u.fsf_-_@gitster.siamese.dyndns.org> (Junio C. Hamano's message of "Sat, 23 Aug 2008 12:56:57 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> The primary logic of the merge, however, had an assumption that the
> process never read the index in-core, and write_cache_as_tree() call it
> makes from write_tree_trivial() will always read from the on-disk index
> the strategies created and write it out as a tree. This assumption is now
> broken by the above fix. It now calls discard_cache() before calling
> write_tree_trivial() when it wants to write the on-disk index as a tree to
> fix this issue.
By the way, in the medium term, if we are serious about making an internal
call to merge_recursive() from cmd_merge(), I think we may be better off
making it the responsibility for try_merge_strategy() to leave an
committable state in the in-core index (aka "the_index") when they return
with 0 (success) status. After calling external ones via the run_command
interface, it should do a read_cache() (after calling discard_cache() if
needed); if it calls merge_recursive(), hopefully you already have the
committable state in the in-core index.
That way, when automerge succeeds, write_tree_trivial() can write that
in-core index out and create the tree object to be committed. The
callchain to use merge_recursive() can avoid having to write to the
on-disk index, read it again and write out the tree from it.
next prev parent reply other threads:[~2008-08-24 2:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-22 6:36 [bug] git `next' does not do trivial merges Paolo Bonzini
2008-08-22 19:31 ` Jeff King
2008-08-23 6:08 ` Miklos Vajna
2008-08-23 8:14 ` [PATCH] Fix in-index merge Miklos Vajna
2008-08-23 8:17 ` [PATCH] builtin-merge: fail properly when we are in the middle of a conflicted merge Miklos Vajna
2008-08-23 9:01 ` Junio C Hamano
2008-08-23 10:57 ` Miklos Vajna
2008-08-23 19:55 ` Junio C Hamano
2008-08-23 19:56 ` [PATCH 1/2] merge: fix numerus bugs around "trivial merge" area Junio C Hamano
2008-08-24 1:58 ` Junio C Hamano [this message]
2008-08-28 13:43 ` [PATCH] builtin-merge: avoid run_command_v_opt() for recursive and subtree Miklos Vajna
2008-08-23 19:57 ` [PATCH 2/2] unpack_trees(): protect the handcrafted in-core index from read_cache() Junio C Hamano
2008-08-23 9:50 ` [PATCH] builtin-merge: fail properly when we are in the middle of a conflicted merge Junio C Hamano
2008-08-23 8:50 ` [PATCH] Fix in-index merge Junio C Hamano
2008-08-23 10:41 ` Miklos Vajna
2008-08-23 9:19 ` Paolo Bonzini
2008-08-23 9:55 ` Junio C Hamano
2008-08-23 10:00 ` Junio C Hamano
2008-08-23 10:41 ` [RFH] two and half potential fixlets to the in-core index handling Junio C Hamano
2008-08-23 18:13 ` Linus Torvalds
2008-08-23 19:14 ` Junio C Hamano
2008-08-23 19:21 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vtzdbuqb6.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=bonzini@gnu.org \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=vmiklos@frugalware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.