Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Charles Bailey <charles@hashpling.org>]

On Thu, Jan 29, 2009 at 12:26:39AM -0800, Junio C Hamano wrote:
> Charles Bailey <charles@hashpling.org> writes:
> 
> > On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:
> >> * cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit
> >>  + mergetool: respect autocrlf by using checkout-index
> >> 
> >
> > Can you hold off on merging this one? I now think that there's a
> > cleaner way of doing this and I would like the opportunity for a
> > rethink.
> 
> Sure, it is not in 'master' yet.
> 
> But it's in 'next', so incremental updates from now on, please.
> 

OK, I've thought again and I still think that this patch is good.

Just so you know what I was thinking...

I felt that the new shell function that calls git checkout-index was a
bit clunky. git checkout-index --temp creates its own temporary file
and then the git mergetool renames this file to the temporary filename
that it had already decided on.

An earlier patch to mergetool was careful to ensure that mergetool
temporaries maintained the file extension of the target file in order
to help syntax highlighting merge tools. For this reason, just using
checkout-index generated filenames is not a sufficient solution.

I had two ideas, the first was that perhaps git mergetool could choose
a temporary naming scheme that could be matched by the appropriate use
of checkout-index --prefix. This would obviously preserve the file
extension but it's fairly obvious that it would have surprising
behaviour for merging files in subfolders.

My last idea would be to add an explicit --to-path= to git
checkout-index. It would make the mergetool code simpler but I'm not
sure how useful it would be in any other circumstance.

-- 
Charles Bailey
http://ccgi.hashpling.plus.com/blog/