From: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
To: Finn Arne Gangstad <finnag@pvv.org>
Cc: Junio C Hamano <gitster@pobox.com>,
"git@vger.kernel.org List" <git@vger.kernel.org>
Subject: [PATCH] Clarify text filter merge conflict reduction docs
Date: Mon, 28 Jun 2010 21:32:50 +0200 [thread overview]
Message-ID: <0cd82ad22a6f240ebcde0c2f3a437a805dae5668.1277753114.git.eyvind.bernhardsen@gmail.com> (raw)
In-Reply-To: <20100628080234.GA7134@pvv.org>
Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
---
How does this look?
This commit should really be squashed into the first one in the series.
Live and learn, next time I'll add new changes in a new commit and put
it _last_. I'll submit a fixed series once we're happy with the
documentation.
- Eyvind
Documentation/gitattributes.txt | 46 ++++++++++++++++++++++-----------------
1 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index b110082..22400c1 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -317,17 +317,16 @@ 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.
+For best results, `clean` should not alter its output further if it is
+run twice ("clean->clean" should be equivalent to "clean"), and
+multiple `smudge` commands should not alter `clean`'s output
+("smudge->smudge->clean" should be equivalent to "clean"). See the
+section on merging below.
-The example "indent" filter is well-behaved in this regard: it will
-accept input that is already correctly indented without modifying it.
-In this case, the lack of a smudge filter means that the clean filter
-_must_ accept its own output without modifying it.
+The "indent" filter is well-behaved in this regard: it will not modify
+input that is already correctly indented. In this case, the lack of a
+smudge filter means that the clean filter _must_ accept its own output
+without modifying it.
Interaction between checkin/checkout attributes
@@ -346,16 +345,23 @@ with `text`, and then `ident` and fed to `filter`.
Merging branches with differing checkin/checkout attributes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-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.
-
-This strategy will break down if a `smudge` filter relies on its input
-having been processed by the corresponding `clean` filter or vice
-versa. Such filters may otherwise work well, but will prevent
-automatic merging.
+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
+where the attribute is not in place would normally cause merge
+conflicts.
+
+To prevent these 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.
+
+As long as a "smudge->clean" results in the same output as a "clean"
+even on files that are already smudged, this strategy will
+automatically resolve all filter-related conflicts. Filters that do
+not act in this way may cause additional merge conflicts that must be
+resolved manually.
Generating diff text
--
1.7.1.575.g383de
next prev parent reply other threads:[~2010-06-28 19:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-27 19:43 [PATCH v4 0/3] CRLF merge conflict reduction, take 4 Eyvind Bernhardsen
2010-06-27 19:43 ` [PATCH v4 1/3] Avoid conflicts when merging branches with mixed normalization Eyvind Bernhardsen
2010-06-28 8:02 ` Finn Arne Gangstad
2010-06-28 19:32 ` Eyvind Bernhardsen [this message]
2010-06-28 20:31 ` [PATCH] Clarify text filter merge conflict reduction docs Finn Arne Gangstad
2010-06-29 16:19 ` Junio C Hamano
2010-06-29 21:18 ` Eyvind Bernhardsen
2010-06-30 17:46 ` Junio C Hamano
2010-06-30 21:32 ` Eyvind Bernhardsen
2010-07-01 3:33 ` Junio C Hamano
2010-06-30 8:20 ` Eyvind Bernhardsen
2010-06-30 15:15 ` Junio C Hamano
2010-06-27 19:43 ` [PATCH v4 2/3] Try normalizing files to avoid delete/modify conflicts when merging Eyvind Bernhardsen
2010-06-27 19:43 ` [PATCH v4 3/3] Don't expand CRLFs when normalizing text during merge Eyvind Bernhardsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0cd82ad22a6f240ebcde0c2f3a437a805dae5668.1277753114.git.eyvind.bernhardsen@gmail.com \
--to=eyvind.bernhardsen@gmail.com \
--cc=finnag@pvv.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).