Re: [RFC] ll-merge: Normalize files before merging

From: Finn Arne Gangstad <finnag@pvv.org>
Date: Jun 11, 2010, 08:36 UTC
Message-ID: <20100611083641.GB31109@pvv.org>
In-Reply-To: <4C11EB0D.20208@viscovery.net>

On Fri, Jun 11, 2010 at 09:51:41AM +0200, Johannes Sixt wrote:

Show 14 quoted lines

> Am 6/11/2010 9:34, schrieb Eyvind Bernhardsen:
> > On 11. juni 2010 07:49, Johannes Sixt wrote:
> >> I think you are going overboard here. Normalization should only happen
> >> only for data that moves from the worktree to the database. But during a
> >> merge, at most one part can come from the worktree, methinks; you are
> >> normalizing all three of them, though.
> > 
> > Well, that's sort of the point.  All three are normalized to (hopefully)
> > minimize the differences between them, increasing the chance of a
> > successful merge.
> 
> I know what your point is. It is still inappropriate to call
> normalize_file() on data that comes from the repository. It is not the
> task of a merge procedure to blindly normalize data.

I don't think this argument holds. If git doesn't call convert_to_git() automatically and you get a merge conflict, git WILL call convert_to_git() on the result anyway when you add it, so it can't be that horrible that this happens automatically for you?

If you add something to .gitattributes that causes the repository representation of a file to change, and then try to merge an older branch, isn't it more helpful if it works than if it fails miserably?

It would probably be more correct to do

conert_to_git(convert_to_work_tree(x)) for the parts taken from base and theirs, in theory I guess that this can be true:

convert_to_git(x) != convert_to_git(convert_to_work_tree(x))

- Finn Arne