Re: Summer of Code project ideas due this Friday

[Jeff King <peff@peff.net>]

On Thu, Mar 10, 2011 at 02:58:07PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > Yes, I don't want to see cleanly merged parts. And "--cc" already does
> > what I want by not showing them.
> 
> Are you sure about that?

Well, no. But my experience has been that its output is useful.

> What "--cc" would show largely depends on what you have in your working
> tree. If your two branches fixed the same bug with very different
> approaches, you may resolve the conflict favouring what one side did while
> discarding everything the other side did. The file in your work tree might
> be the same as "git checkout --ours $that_path" after a mergy operation.
> "diff --cc" won't show anything to you in such a case.

Actually, I think diff --cc is doing what I want there. If I take one
side's content completely, then it is not interesting to me anymore.
What I am really concerned about is doing a tricky content-level merge
in my editor and then screwing up the result. Or _trying_ to take one
side of the merge, and then screwing it up. So the "diff --cc" output
after I have mucked is useful for both those cases.

> And as I repeatedly said, grabbing "--cc file" must be done before the
> user starts mucking with the file in the working tree for the approach to
> be any useful.

I'm not sure I agree. The output after I have mucked is useful to me,
and that is what this use-case is based on. So I think we are talking
about related but slightly different use cases.

> > Which really I could do with:
> >
> >   for i in `git diff-files --name-only --diff-filter=U`; do
> >     git diff --cc $i
> >     echo 'OK?'
> 
> As you already know, I disagree the usefulness of this approach (see the
> "Are you sure about that?" discussion), hence I doubt the usefulness of
> "have it integrated into the "git add -p" loop".

OK, let me put it this way. I am not volunteering to work on the
approach you outlined. If you are, great. But if not, then what should
be done? The current behavior to show the diff and then exit is quite
confusing. At the very least, we should say something to the user about
what happened (or even suppress the diff and just say "these paths are
unmerged, and we can't handle them in add -p").

-Peff