From: Junio C Hamano <junkio@cox.net>
To: Fredrik Kuivinen <freku045@student.liu.se>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/2] A new merge algorithm, take 3
Date: Wed, 07 Sep 2005 11:36:48 -0700 [thread overview]
Message-ID: <7v1x407min.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20050907164734.GA20198@c165.ib.student.liu.se> (Fredrik Kuivinen's message of "Wed, 7 Sep 2005 18:47:34 +0200")
Fredrik Kuivinen <freku045@student.liu.se> writes:
> I guess the need for this has decreased with Daniel's new read-tree
> code. Is there any chance of getting this code merged into mainline
> git?
I do not think Daniel's code decreased anything. The two
algorithms are solving the same problem but they do it
differently. There would be cases where multi-base merge would
give better results over your base-on-merge-bases merge; and in
other cases yours would perform better. I'd like to leave what
merge strategy to use as an user option, and leave the door open
for other merge strategies to emerge later. I know Pasky wants
to look into pcdv merge and other alternatives.
This is still off-the-top-of-my-head, but the top-level merge
entry point for the end user would be just:
git merge <head> <remote> <merge-message>
and by default 'git-merge-script' (sorry, I am taking over the
name of your script for this 'generic driver for underlying
merge strategy scripts') would do something like:
- Run 'git-merge-base -a' to find common ancestors.
- If there is one single common ancestor, do what the current
'git-resolve-script' does: if fast-forward, declare success
and exit without touching anything but $GIT_DIR/HEAD;
otherwise, run read-tree -m 3-way followed by merge-cache,
and commit with the given message if the merge was clean and
exit. If the merge was not clean, go on to the next step.
- User preference (maybe $HOME/.git/merge-preference, maybe
command line option to 'git merge', maybe interactive
prompting) can specify which complex merge strategies to use.
we probably would want to be able to say "try this, that and
that-over-there in this order" in the preference. One of the
strategies could be 'I give up, just exit and sort it out by
hand'.
- The chosen merge backend, be it the one that uses Daniel's
multi-base merge or your base-on-merge-bases merge, takes
over. In any case, the backend should attempt to resolve the
two heads, and stop at the point just before committing.
- Evaluate how good the merge is by looking at the result from
the backend at this point, and if it is not good enough,
reset the working tree back to the pre-merge state and try
the next backend. The looping code needs a termination
clause that picks the best result after exhausting the list
of backends.
- Then, if the merge backend auto-resolved the heads, we
commit with <merge-message>; otherwise we exit with
non-zero status and have the user sort it out.
The above assumes that (1) we are already doing a reasonable
thing in simple one-common-ancestor case; (2) it is in the fast
path and we want the multiple backend code out of it. You could
think of the current 'git-resolve-script' code equivalent of
having a single 'complex merge backend' that just 'gives up'.
If the above is a good user model, we need a couple of interface
convention between merge backends and the above driver:
- Some merge backends (like yours) would require that the
starting tree is clean while others may not care as long as
the paths involved are clean (i.e. index matches <head> and
the working file matches index -- the traditional code and
Daniel's even allow such a working file being different from
index if it happens to match the merge result). They need to
be able to say "declined to merge even though I might do a
better job than others if given a clean working tree". Then
the user can retry the same merge after getting the working
tree in a clean state. I personally feel that we do not need
this complexity and it is reasonable to always require the
starting tree to be clean when the merge is not a
fast-forward, though.
- When a merge backend finishes, it may leave the working tree
in a failed merge state. If we were to try different
backends in the loop to find the best result, we would need
some way to assign scores to them. The score should be able
to tell us if the result can be auto-committable or not, and
if not how bad it is. I think exit status from the backend
can be used to tell us the former (i.e. exit non-zero if your
result has conflicts and you do not want your result to be
committed immediately), and number of cache-dirty entries can
be used as an indication of how bad it is (i.e. leave the
paths you know have not been cleanly merged cache-dirty -- do
not run git-update-cache on them). This is essentially the
same convention used by the current 'git-resolve-script'.
I think the 'renaming merge heuristics' Linus outlined in
another thread will fall naturally into this picture as a merge
backend.
next prev parent reply other threads:[~2005-09-07 18:36 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-07 16:47 [PATCH 0/2] A new merge algorithm, take 3 Fredrik Kuivinen
2005-09-07 16:50 ` [PATCH 1/2] Add '-i' flag to read-tree to make it ignore whats in the working directory Fredrik Kuivinen
2005-09-11 2:54 ` Unified merge driver pushed out to "master" branch Junio C Hamano
2005-09-11 21:05 ` Fredrik Kuivinen
2005-09-12 1:23 ` Junio C Hamano
2005-09-14 5:56 ` Another merge test case from the kernel tree Junio C Hamano
2005-09-14 16:11 ` Daniel Barkalow
2005-09-14 16:30 ` Junio C Hamano
2005-09-14 17:42 ` Fredrik Kuivinen
2005-09-14 17:51 ` Junio C Hamano
2005-09-15 0:47 ` Yet another set of merge test cases " Junio C Hamano
2005-09-19 16:13 ` Fredrik Kuivinen
2005-09-20 1:53 ` Junio C Hamano
2005-09-20 5:50 ` Fredrik Kuivinen
2005-09-07 16:51 ` [PATCH 2/2] A new merge algorithm Fredrik Kuivinen
2005-09-07 18:33 ` [PATCH 0/2] A new merge algorithm, take 3 Daniel Barkalow
2005-09-08 6:06 ` Fredrik Kuivinen
2005-09-08 15:27 ` Daniel Barkalow
2005-09-08 20:05 ` Fredrik Kuivinen
2005-09-08 21:27 ` Daniel Barkalow
2005-09-07 18:36 ` Junio C Hamano [this message]
[not found] ` <431F34FF.5050301@citi.umich.edu>
[not found] ` <7vvf1cz64l.fsf@assigned-by-dhcp.cox.net>
2005-09-08 15:06 ` Chuck Lever
2005-09-08 16:51 ` Junio C Hamano
2005-09-08 17:19 ` Linus Torvalds
2005-09-08 17:51 ` Junio C Hamano
2005-09-08 18:16 ` Chuck Lever
2005-09-08 18:35 ` Linus Torvalds
2005-09-08 18:58 ` Chuck Lever
2005-09-08 20:59 ` Linus Torvalds
2005-09-09 7:44 ` [RFH] Merge driver Junio C Hamano
2005-09-09 16:05 ` Daniel Barkalow
2005-09-09 16:43 ` Junio C Hamano
2005-09-09 17:25 ` Daniel Barkalow
2005-09-11 4:58 ` Junio C Hamano
2005-09-12 21:08 ` Fredrik Kuivinen
2005-09-12 21:16 ` Junio C Hamano
2005-09-13 20:33 ` Fredrik Kuivinen
2005-09-13 20:46 ` Junio C Hamano
2005-09-08 20:54 ` [PATCH 0/2] A new merge algorithm, take 3 Junio C Hamano
2005-09-08 21:23 ` A Large Angry SCM
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v1x407min.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=freku045@student.liu.se \
--cc=git@vger.kernel.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).