Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

From: Finn Arne Gangstad <finnag@pvv.org>
Date: Jun 24, 2010, 11:58 UTC
Message-ID: <20100624115855.GA22684@pvv.org>
In-Reply-To: <4C2344C0.2010402@viscovery.net>

On Thu, Jun 24, 2010 at 01:42:56PM +0200, Johannes Sixt wrote:

Show 21 quoted lines

> Am 6/24/2010 13:17, schrieb Finn Arne Gangstad:
> > Assume you start out with a repo that has a lot of text files with
> > CRLF checked in (A).
> > 
> >   C----
> >  /     \
> > A---B---D
> > 
> > B: Add "* text=auto" to .gitattributes and normalize all files to LF
> > only in repo
> > 
> > D: try to merge C
> > 
> > Without this patch you will get a ridiculous number of lf/crlf
> > conflicts when trying to merge C into D, since the repository contents
> > for C are "wrong" wrt the new .gitattributes file.
> 
> What should happen when you have C checked out (i.e., you do not yet have
> the updated .gitattributes in your worktree nor index) and merge B?
> Currently, you get the identical conflicts, but I suspect that the patch
> does not help in this situation. IOW, it breaks the merge symmetry.

git merges .gitattributes early, so it will work any way you do the merge I think? Each file in a merge is processed separately with whatever .gitattributes file is active.

If you get a conflict in .gitattributes you may be in a slightly interesting spot, but you will still get all the new attributes in the conflicted file, so in practice it should still work. git ignores the conflict markers in .gitattributes and moves on..

- Finn Arne