Re: Summer of Code project ideas due this Friday

From: Jeff King <peff@peff.net>
Date: Mar 10, 2011, 23:09 UTC
Message-ID: <20110310230958.GI15828@sigill.intra.peff.net>
In-Reply-To: <7v8vwm37nk.fsf@alter.siamese.dyndns.org>

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

Show 6 quoted lines

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

Show 6 quoted lines

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

Show 9 quoted lines

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