From: Junio C Hamano <junkio@cox.net>
To: Fredrik Kuivinen <freku045@student.liu.se>,
Daniel Barkalow <barkalow@iabervon.org>,
Linus Torvalds <torvalds@osdl.org>
Cc: cel@citi.umich.edu, git@vger.kernel.org
Subject: [RFH] Merge driver
Date: Fri, 09 Sep 2005 00:44:40 -0700 [thread overview]
Message-ID: <7v3boen0rb.fsf_-_@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <432089D8.4060507@citi.umich.edu> (Chuck Lever's message of "Thu, 08 Sep 2005 14:58:32 -0400")
I have several requests to people who are interested in merges
and read-tree changes.
I am pretty much set to use the recent read-tree updates Daniel
has been working on. The only reason it has not hit the
"master" branch yet, except that it still has known leaks that
have not been plugged, is because read-tree is so fundamental to
everything we do, and I am trying to be extremely conservative
here. I've beaten it myself reasonably well and have not found
any regressions (except removal of --emu23 which I believe
nobody uses anyway), but I'd appreciate people to try it out and
see if it performs well for your dataset.
If you are planning further surgery on read-tree code, please
base your changes on Daniel's rewrite to avoid your effort being
wasted. This request goes both to Chuck (active_cache
abstraction) and Fredrik (addition of 'ignore index and working
tree matching rules' [*1*]).
A proposed merge driver 'git-merge' is in the proposed updates
branch. This is intended to be the top-level user interface to
the merge machinery which drives multiple merge strategy
scripts, and I am hoping that I can eventually (1) retire
'git-resolve' and 'git-octopus' (they simply become merge
strategy scripts driven by 'git-merge') and (2) call 'git-merge'
from 'git-pull'. What I have in the proposed updates branch has
been fixed since my earlier message to the list and has a new
merge strategy script, in addition to 'resolve' and 'octopus',
called 'git-merge-multibase'. This uses Daniel's read-tree that
can use more than one merge bases. I request Daniel to give OK
to its name or suggest a better name for this script -- I would
even accept 'git-merge-barkalow' if you want ;-).
If you are planning to implement a new merge strategy, please
use the ones in the proposed updates branch as examples, and
complain and suggest improvements if you find the interface
between the strategy scripts and the driver lacking. This
request goes primarily to Fredrik. I'm interested in doing the
renaming merge that would have helped HPA's klibc-kbuild vs
klibc case myself but if somebody else is so inclined please go
wild.
And finally, a request to everybody; please try out 'git-merge'
and see how you like it.
`git-merge` [-n] [-s <strategy>]... <msg> <head> <remote> <remote>...
-n::
Do not show diffstat at the end of the merge.
-s <strategy>::
use that merge strategy; can be given more than once to
specify them in the order they should be tried. If
there is no `-s` option, built-in list of strategies is
used instead.
<head>::
our branch head commit.
<remote>::
other branch head merged into our branch. You need at
least one <remote>. Specifying more than one <remote>
obviously means you are trying an Octopus.
Here is a sample transcript from a test resolving one of the
'more-than-one-merge-base' commits Fredrik found in the kernel
repository (": siamese;" is my $PS1; " " is my $PS2).
: siamese; git reset --hard b8112df71cae7d6a86158caeb19d215f56c4f9ab
: siamese; git merge -n \
'reproduce 0e396ee43e445cb7c215a98da4e76d0ce354d9d7' \
HEAD 2089a0d38bc9c2cdd084207ebf7082b18cf4bf58
Trying merge strategy resolve...
Trying to find the optimum merge base.
Trying simple merge.
Simple merge failed, trying Automatic merge.
Removing drivers/net/fmv18x.c
Auto-merging drivers/net/r8169.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/net/r8169.c.
Removing drivers/net/sk_g16.c
Removing drivers/net/sk_g16.h
fatal: merge program failed
Rewinding the tree to pristine...
Trying merge strategy multibase...
Trying simple merge.
Simple merge failed, trying Automatic merge.
Removing drivers/net/fmv18x.c
Auto-merging drivers/net/r8169.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/net/r8169.c.
Removing drivers/net/sk_g16.c
Removing drivers/net/sk_g16.h
fatal: merge program failed
Rewinding the tree to pristine...
Trying merge strategy octopus...
Rewinding the tree to pristine...
Using the multibase to prepare resolving by hand.
Trying simple merge.
Simple merge failed, trying Automatic merge.
Removing drivers/net/fmv18x.c
Auto-merging drivers/net/r8169.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/net/r8169.c.
Removing drivers/net/sk_g16.c
Removing drivers/net/sk_g16.h
fatal: merge program failed
Automatic merge failed; fix up by hand
: siamese; git-update-cache --refresh
drivers/net/r8169.c: needs update
: siamese; echo $?
1
: siamese; git diff -r 0e396ee43e445cb7c215a98da4e76d0ce354d9d7
:100644 100644 ce449fe 0000000 M drivers/net/r8169.c
: siamese; exit
In the above example, 'resolve', 'multibase' and 'octopus' are
tried in turn (actually, 'octopus' notices that it is given only
one <remote> and refuses to do anything without wasting time).
Since all of these strategies fail to fully auto-merge the given
heads, and 'multibase' gives the smallest number of conflicts,
its result is left in the working tree for the user to resolve
by hand. You resolve this and commit the same way as you
currently do with 'git-resolve' that results in conflicts.
[Footnote]
*1* Fredrik, I have been wondering if we can just say that lack
of '-u' flag implies '-i'. Is there a good reason that
'git-read-tree -m O A B' without '-u' should care if working
tree is up to date for the paths involved?
next prev parent reply other threads:[~2005-09-09 7:44 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
[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 ` Junio C Hamano [this message]
2005-09-09 16:05 ` [RFH] Merge driver 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=7v3boen0rb.fsf_-_@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=barkalow@iabervon.org \
--cc=cel@citi.umich.edu \
--cc=freku045@student.liu.se \
--cc=git@vger.kernel.org \
--cc=torvalds@osdl.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).