Git Mailing List Archive mirror
 help / color / mirror / Atom feed
From: John Whitney <jjw@emsoftware.com>
To: Jeff King <peff@peff.net>
Cc: Phil Hord <phil.hord@gmail.com>, git@vger.kernel.org
Subject: Re: Bug report
Date: Sat, 06 Oct 2012 21:23:59 -0500	[thread overview]
Message-ID: <5070E7BF.8040102@emsoftware.com> (raw)
In-Reply-To: <20121006133146.GD11712@sigill.intra.peff.net>

On 10/6/12 8:31 AM, Jeff King wrote:
> On Thu, Oct 04, 2012 at 11:10:40AM -0500, John Whitney wrote:
>
>> Thank you for your response. I do see the dilemma, but having
>> no possible "unmodified" state is extremely inconvenient and,
>> as shown, breaks basic git operations.
> But you have asked for an impossible state. You have said "this file
> cannot have CR when you check it in, because we erase them". And yet the
> version of the file in HEAD has CRs in it. So it must appear modified
> with respect to HEAD.  And the solution is to make a commit with the
> normalized content.
I guess I'd really like to see git ignore all line endings of text files 
in the repository. Text files would then never be marked as "modified" 
for this reason and there would be no need to "fix" the line endings. I 
think that should be the default, but just having the option would be nice.

> You said in your test script:
>
>    # Committing test.txt or clearing .gitattributes does clear
>    # the "modified" status, but those options are undesirable
>
> Why is the commit undesirable? You have decided that CRs will no longer
> be tolerated in your repository (by setting .gitattributes). Now you
> need to record that change in history with a commit that strips out the
> CRs.
In some cases it's undesirable. In my example, all I want to do is merge 
in the change that deletes the file, so I don't want to have to add that 
extra commit when I'm just going to delete the file anyway. It's also 
very inconvenient to have to deal with this issue when you're in the 
middle of a complex rebase operation.

>> I guess my thought is that if git doesn't allow CRs to be checked
>> in, then it should strip the CRs when checking the file out, and
>> consider that form (or both forms) as "unmodified". It just
>> doesn't make sense to me that files are considered modified
>> immediately after checkout.
> It is not about having CRs in the working tree file. Those are now
> considered uninteresting and stripped by git when comparing to the HEAD.
> The problem is that what's in your _repository_ has CRs.
Yes, but does that really have to be an issue? Is there any technical or 
practical reason you can think of that the repository shouldn't ignore 
those CRs?

> I wonder if this is a fundamental misunderstanding of how the CRLF
> handling in git works. It is not "magically make me not care about line
> endings anymore". It is "the canonical version in the repo is LF-only.
> Strip anything coming into the repository to match that, and
> (optionally) add CR to anything going out to the filesystem for my
> convenience". But you need a flag day to update the in-repository
> versions to the new scheme.
>
> -Peff
You're right, we can't magically avoid all the line ending issues that 
people will run into. In this case, though, I think git can sidestep a 
fairly obnoxious problem. My example was simple, but when you've got 
multiple branches that need to be rebased/merged, it can get pretty 
hairy. The repository will never be truly "clean" unless you rewrite the 
whole thing (using filter-branch, for instance).

Maybe my above suggestion is more of a feature request than a bug, but 
there is the obvious bug that after changing .gitattributes, git still 
doesn't notice that files are "modified" until you modify them again in 
some way (touch works). I only noticed the CRs in our own repository 
after I tried to rebase a branch and got strange errors. To make git 
notice all the files, I had to "find . -type f -exec touch {} \;".

  reply	other threads:[~2012-10-07  2:24 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-04  4:35 Bug report John Whitney
2012-10-04 14:19 ` Phil Hord
2012-10-04 16:10   ` John Whitney
2012-10-06 13:31     ` Jeff King
2012-10-07  2:23       ` John Whitney [this message]
2012-10-07 23:52         ` Jeff King
2012-10-09 17:17           ` John Whitney
2012-10-09 19:00             ` John Whitney
2012-10-04 15:21 ` Andrew Wong
2012-10-04 16:16   ` John Whitney
2012-10-04 16:28     ` John Whitney
2012-10-04 17:01     ` Andrew Wong
  -- strict thread matches above, loose matches on Subject: below --
2012-10-05 10:13 Муковников Михаил
2012-10-05 10:32 ` Konstantin Khomoutov
2012-10-05 10:47   ` Carlos Martín Nieto
2012-10-05 11:03     ` Муковников Михаил
2012-10-05 10:52   ` Муковников Михаил
     [not found] <CAC34_pT9zwZDnUjo1bTUZabD02M48=_+77-mNCA5adWTgxuYgg@mail.gmail.com>
2013-04-08  5:20 ` Bug Report Kirk Fraser
2015-01-27 14:43 bug report Albert Akhriev
2015-01-27 14:50 ` Jeff King
2016-04-03  0:25 Bug Report Benjamin Sandeen
2016-04-03  2:20 ` Eric N. Vander Weele
2016-04-03  2:22 ` Jacob Keller
2016-05-13  5:04 bug report 李本超
2016-05-13  5:23 ` Pranit Bauva
2016-05-13  5:58   ` 李本超
2016-05-13  6:37     ` Pranit Bauva
2016-05-13  6:57       ` 李本超
2016-05-13  7:10         ` Pranit Bauva
2016-05-13  7:41           ` 李本超
2016-05-13  8:10             ` Jeff King
2016-05-13 12:05               ` 李本超
2017-08-30 21:25 Bug report Aleksandar Pavic
2017-08-31  6:36 ` Kevin Daudt
2017-08-31 14:19   ` Dov Grobgeld
2017-08-31 14:55     ` Aleksandar Pavic
2017-08-31 16:23   ` Stephan Beyer
2017-09-02  8:49 ` Jeff King
     [not found] <CA+2sEepTyrK-iH+VBHVF1i9DuYVzDkTNxuM0-yoWbkC9N4f8HA@mail.gmail.com>
2019-04-15 15:18 ` bug report Nick Steinhauser
2020-03-27 11:53 Bug Report James Yeoman
2020-03-27 12:59 ` Pratyush Yadav
2021-11-12  4:22 bug report Theodore Li
2021-11-12  4:29 ` Junio C Hamano
2021-11-12  6:59   ` Theodore Li
2021-11-12 14:05     ` Paul Smith
2021-12-01 22:31 Bug Report Josh Rampersad
2022-04-20 19:45 Daniel Habenicht
2022-04-20 21:30 ` brian m. carlson
2022-04-20 22:34   ` rsbecker
2022-04-21 13:20     ` Daniel Habenicht
2022-04-21 14:39       ` Torsten Bögershausen
     [not found]         ` <AS1P190MB175022A7F1264807ECA464A8ECF49@AS1P190MB1750.EURP190.PROD.OUTLOOK.COM>
2022-04-21 17:52           ` Torsten Bögershausen
2022-10-03 15:28 Bug report Alastair Douglas
2022-10-03 16:53 ` Junio C Hamano
2022-10-04 10:15   ` Alastair Douglas
2022-10-05  5:46     ` Junio C Hamano
2022-11-19 20:20 Bug Report Jensen Bean
2022-12-08  5:29 Jensen Bean
2022-12-08  8:31 ` Bagas Sanjaya
     [not found]   ` <CANqKdC-gHgQHn5DMoOREY52y7PpRLMpNAjX3qeA5iy9z_GXdzw@mail.gmail.com>
2022-12-26  2:15     ` Bagas Sanjaya
2022-12-25 17:26 bug report Eyal Post
2022-12-25 18:12 ` Eric Sunshine
2022-12-28  2:43 Bug report Jensen Bean
2022-12-28  5:02 ` Eric Sunshine
2023-06-27 16:02 Bug Report Tiago d'Almeida
2023-08-28 12:51 Bug report Dexter Pontañeles

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=5070E7BF.8040102@emsoftware.com \
    --to=jjw@emsoftware.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=phil.hord@gmail.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 read-only IMAP folder(s) and NNTP newsgroup(s).