From: Daniel Barkalow <barkalow@iabervon.org>
To: Junio C Hamano <junkio@cox.net>
Cc: Fredrik Kuivinen <freku045@student.liu.se>,
Linus Torvalds <torvalds@osdl.org>,
cel@citi.umich.edu, git@vger.kernel.org
Subject: Re: [RFH] Merge driver
Date: Fri, 9 Sep 2005 12:05:33 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.63.0509091151520.23242@iabervon.org> (raw)
In-Reply-To: <7v3boen0rb.fsf_-_@assigned-by-dhcp.cox.net>
On Fri, 9 Sep 2005, Junio C Hamano wrote:
> 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 ;-).
I'd actually been thinking it would just go into the the "resolve" driver,
with that going back to before it chose among merge-base outputs and just
sending the whole list to read-tree.
> 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.
This is no good: the current 'resolve' can generate wrong results and
report that it worked cleanly, while 'multibase' would report a conflict
because it isn't ignoring a real problem. My primary goal in doing the
multibase version wasn't to produce more clean merges; it was to produce
fewer clean-but-wrong merges.
> [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?
It tries to make sure that there is room to put stuff for resolving a
conflict without messing with modified files in the directory.
next prev parent reply other threads:[~2005-09-09 16:01 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 ` [RFH] Merge driver Junio C Hamano
2005-09-09 16:05 ` Daniel Barkalow [this message]
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=Pine.LNX.4.63.0509091151520.23242@iabervon.org \
--to=barkalow@iabervon.org \
--cc=cel@citi.umich.edu \
--cc=freku045@student.liu.se \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--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).