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

Re: [PATCH v4 1/3] Avoid conflicts when merging branches with mixed normalization

From
Finn Arne Gangstad <finnag@pvv.org>
Date
Jun 28, 2010, 08:02 UTC
Message-ID
<20100628080234.GA7134@pvv.org>
In-Reply-To
<07a766a7972671b9e39dbca55719d024c30c7a28.1277667177.git.eyvind.bernhardsen@gmail.com>
Show 12 quoted lines
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -317,6 +317,18 @@ command is "cat").
>  	smudge = cat
>  ------------------------
>  
> +For best results, `clean` and `smudge` commands should produce output
> +that is not dependent on the corresponding command having been run.
> +That is, `clean` should produce identical output whether its input has
> +been run through `smudge` or not, and `smudge` should not rely on its
> +input having been run through `clean`.  See the section on merging
> +below for a rationale.
I think this is marginally unclear, what about:
  Clean should not alter its output further if run again
  clean(x) == clean(clean(x))
  Smudge should not alter the output of clean
  clean(x) == clean(smudge(x))

It should not matter that smudge will do something weird if clean hasn't been run, as long as clean(x) == clean(smudge(x)) still holds. I also think it is worth mentioning explicitly that clean can be run multiple times, you should not have to infer this.

> [...]
> +Merging branches with differing checkin/checkout attributes
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Maybe something about when this happens, or even put it in the header instead? Something like

  If you have added attributes to a file that cause the canonical
  repository format for that file to change, such as adding a
  clean/smudge filter or text/eol/ident attributes, merging anything based
  on a point in time where the attribute was not in place would normally
  cause merge conflicts.
Show 6 quoted lines
> +
> +To prevent unnecessary merge conflicts, git runs a virtual check-out
> +and check-in of all three stages of a file when resolving a three-way
> +merge.  This prevents changes caused by check-in conversion from
> +causing spurious merge conflicts when a converted file is merged with
> +an unconverted file.
- Finn Arne
Previous: Eyvind BernhardsenNext: Eyvind Bernhardsen
Message 3 of 14 in “CRLF merge conflict reduction, take 4”
  1. 0/3 CRLF merge conflict reduction, take 4Eyvind Bernhardsen, Jun 27, 2010
  2. 1/3 Avoid conflicts when merging branches with mixed normalizationEyvind Bernhardsen, Jun 27, 2010
  3. Finn Arne GangstadJun 28, 2010
  4. Clarify text filter merge conflict reduction docsEyvind Bernhardsen, Jun 28, 2010
  5. Finn Arne GangstadJun 28, 2010
  6. Junio C HamanoJun 29, 2010
  7. Eyvind BernhardsenJun 29, 2010
  8. Junio C HamanoJun 30, 2010
  9. Eyvind BernhardsenJun 30, 2010
  10. Junio C HamanoJul 1, 2010
  11. Eyvind BernhardsenJun 30, 2010
  12. Junio C HamanoJun 30, 2010
  13. 2/3 Try normalizing files to avoid delete/modify conflicts when mergingEyvind Bernhardsen, Jun 27, 2010
  14. 3/3 Don't expand CRLFs when normalizing text during mergeEyvind Bernhardsen, Jun 27, 2010

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.