Johannes Schindelin writes:
> To the contrary. As far as I can see, when calling `git merge`, Git
> currently *does* read .gitattributes from the file, and if that fails,
> falls back to reading that file from the index.
Hmph.
Assuming that the merge always goes in the index order, I think you
Hi Junio,
On Mon, 17 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > I would vote for:
> >
> > 4. We keep letting Git read in the *current* version of .gitattributes
> >*before* the merge, and apply those attributes while performing the
> >merge.
>
> Even though thi
Johannes Schindelin writes:
> I would vote for:
>
> 4. We keep letting Git read in the *current* version of .gitattributes
>*before* the merge, and apply those attributes while performing the
>merge.
Even though this needs a major surgery to the way the attr subsystem
reads from these fi
Hi Lars,
On Tue, 4 Oct 2016, Lars Schneider wrote:
> If there is a conflict in the .gitattributes during a merge then it looks
> like as if the attributes are not applied
I tried to replicate this behavior, to the point where I wrote a patch
that demonstrates the breakage so I could single-step
On Tue, Oct 4, 2016 at 5:19 PM, Lars Schneider wrote:
> Hi,
>
>
> If there is a conflict in the .gitattributes during a merge then it looks
> like as if the attributes are not applied (which kind of makes sense as Git
> would not know what to do). As a result Git can treat e.g. binary files
> as t
Hi,
If there is a conflict in the .gitattributes during a merge then it looks
like as if the attributes are not applied (which kind of makes sense as Git
would not know what to do). As a result Git can treat e.g. binary files
as text and they can end up with changed line endings in the working
6 matches
Mail list logo