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

From: Charles Bailey <charles@hashpling.org>
Date: Jan 29, 2009, 09:16 UTC
Message-ID: <20090129091611.GB10490@hashpling.org>
In-Reply-To: <7vbptqh60w.fsf@gitster.siamese.dyndns.org>

On Thu, Jan 29, 2009 at 12:26:39AM -0800, Junio C Hamano wrote:

Show 15 quoted lines

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