git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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.

  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).