From: "Martin Ågren" <firstname.lastname@example.org> To: "brian m. carlson" <email@example.com> Cc: Git Mailing List <firstname.lastname@example.org> Subject: Re: [PATCH 3/3] docs: explain how to deal with files that are always modified Date: Sun, 13 Sep 2020 17:13:10 +0200 [thread overview] Message-ID: <CAN0heSp-Uhp9QZdjV3GeUkhMn513-GADJg1D9UXsrB7ok8J_gw@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Sat, 12 Sep 2020 at 22:52, brian m. carlson <firstname.lastname@example.org> wrote: > > Users frequently have problems where two files differ only in case, s/files/filenames/ ? Anyway, clear enough here, but let's keep it in mind when reading the proposed FAQ entry.. > causing one of those files to show up consistently as being modified. > Let's add a FAQ entry that explains how to deal with that. > > In addition, let's explain another common case where files are > consistently modified, which is when files using a smudge or clean > filter have not been run through that filter. Explain the way to fix > this as well. > +Why do I have a file that's always modified?:: > + Internally, Git always stores file names as sequences of bytes and doesn't > + perform any encoding or case folding. However, Windows and macOS by default > + both perform case folding on file names. As a result, it's possible to end up > + with multiple files or directories that differ in case. Git can handle this I think this could be clearer with something like s/that differ in case/where their names only differ in case/, i.e., explicitly talking about the names of the files and also sticking an "only" in there. > + just fine, but the file system can store only one of these files, so when Git > + reads the other file to see its contents, it looks modified. That concludes my reading of these patches. I only had some minor comments. I think these are good entries to add to the FAQ. Martin
next prev parent reply other threads:[~2020-09-13 15:13 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-12 20:48 [PATCH 0/3] FAQ entries for merges and modified files brian m. carlson 2020-09-12 20:48 ` [PATCH 1/3] docs: explain why squash merges are broken with long-running branches brian m. carlson 2020-09-13 15:05 ` Martin Ågren 2020-09-13 17:12 ` brian m. carlson 2020-09-12 20:48 ` [PATCH 2/3] docs: explain why reverts are not always applied on merge brian m. carlson 2020-09-13 15:12 ` Martin Ågren 2020-09-12 20:48 ` [PATCH 3/3] docs: explain how to deal with files that are always modified brian m. carlson 2020-09-13 15:13 ` Martin Ågren [this message] 2020-09-12 21:48 ` [PATCH 0/3] FAQ entries for merges and modified files Junio C Hamano 2020-09-20 23:22 ` [PATCH v2 " brian m. carlson 2020-09-20 23:22 ` [PATCH v2 1/3] docs: explain why squash merges are broken with long-running branches brian m. carlson 2020-09-20 23:22 ` [PATCH v2 2/3] docs: explain why reverts are not always applied on merge brian m. carlson 2020-09-20 23:22 ` [PATCH v2 3/3] docs: explain how to deal with files that are always modified brian m. carlson
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 List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAN0heSp-Uhp9QZdjV3GeUkhMn513-GADJg1D9UXsrB7ok8J_gw@mail.gmail.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 3/3] docs: explain how to deal with files that are always modified' \ /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
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git 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 read-only IMAP folder(s) and NNTP newsgroup(s).