git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Merge conflicts in .gitattributes can cause trouble

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 17, 2016, 17:51 UTC
Message-ID
<xmqqvawqvp6y.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<alpine.DEB.2.20.1610171803400.197091@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 5 quoted lines
> 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 files, I think it is conceptually the cleanest.

Previous: Johannes SchindelinNext: Johannes Schindelin
Message 4 of 6 in “Merge conflicts in .gitattributes can cause trouble”
  1. Lars SchneiderOct 4, 2016
  2. Duy NguyenOct 4, 2016
  3. Johannes SchindelinOct 17, 2016
  4. Junio C HamanoOct 17, 2016
  5. Johannes SchindelinOct 18, 2016
  6. Junio C HamanoOct 18, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.