Re: [RFH] Merge driver

2005-09-09 Thread Daniel Barkalow 
On Fri, 9 Sep 2005, Junio C Hamano wrote:

> Daniel Barkalow <[EMAIL PROTECTED]> writes:
> 
> > It tries to make sure that there is room to put stuff for resolving a 
> > conflict without messing with modified files in the directory.
> 
> I agree it can be used that way, but nobody seems to use it for
> that purpose as far as I can tell hence my earlier comment.  But
> let's leave the door open by having them as independent
> options.

Ah, okay. I hadn't realized that resolve used -u for that call to 
read-tree. You're entirely right.

-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] Merge driver

2005-09-09 Thread Junio C Hamano 
Daniel Barkalow <[EMAIL PROTECTED]> writes:

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

True.  Before 'git-merge' hits the "master" branch I should
remove 'git-merge-resolve' from the strategies list (or rename
'git-merge-multibase' to it).  I have them separately only
because I wanted to be able to see how differently they perform
by saying:

git merge -s resolve blah...
git merge -s multibase blah...

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

I agree it can be used that way, but nobody seems to use it for
that purpose as far as I can tell hence my earlier comment.  But
let's leave the door open by having them as independent
options.


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] Merge driver

2005-09-09 Thread Daniel Barkalow 
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 ]......
> 
> -n::
>   Do not show diffstat at the end of the merge.
> 
> -s ::
>   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.
> 
> ::
>   our branch head commit.
> 
> ::
>   other branch head merged into our branch.  You need at
>   least one .  Specifying more than one 
>   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
>