Re: Line ending normalization doesn't work as expected

On Fri, Feb 16, 2018 at 10:34 AM, Torsten Bögershausen wrote: > On Thu, Feb 15, 2018 at 09:24:40AM -0600, Robert Dailey wrote: >> On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano wrote: > > [] >> >> Sorry to bring this old thread back to life, but I did notice

Re: Line ending normalization doesn't work as expected

On Thu, Feb 15, 2018 at 09:24:40AM -0600, Robert Dailey wrote: > On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano wrote: [] > > Sorry to bring this old thread back to life, but I did notice that > this causes file modes to reset back to 644 (from 755) on Windows > version of

Re: Line ending normalization doesn't work as expected

On Thu, Feb 15, 2018 at 1:16 PM, Junio C Hamano wrote: > I think the message you are referring to is a tangent that discusses > how it was done in the old world, with issues that come from the > fact that with such an approach the paths are first removed from the > index and

Re: Line ending normalization doesn't work as expected

Robert Dailey writes: > On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano wrote: >> Torsten Bögershausen writes: >> $ git rm -r --cached . && git add . >>> >>> (Both should work) >>> >>> To be honest, from the documentation, I can't

Re: Line ending normalization doesn't work as expected

On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano wrote: > Torsten Bögershausen writes: > >>> $ git rm -r --cached . && git add . >> >> (Both should work) >> >> To be honest, from the documentation, I can't figure out the difference >> between >> $ git read-tree

Re: Line ending normalization doesn't work as expected

On Fri, Oct 06, 2017 at 09:33:31AM +0900, Junio C Hamano wrote: > Torsten Bögershausen writes: > > > Before we put this into stone: > > Does it make sense to say "renormalize" instead of "rehash" ? > > (That term does exist already for merge. > > And rehash is more a technical

Re: Line ending normalization doesn't work as expected

Torsten Bögershausen writes: > Before we put this into stone: > Does it make sense to say "renormalize" instead of "rehash" ? > (That term does exist already for merge. > And rehash is more a technical term, rather then a user-point-of-view > explanation) I do not mind

Re: Line ending normalization doesn't work as expected

> builtin/add.c | 42 +- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/builtin/add.c b/builtin/add.c > index 5d5773d5cd..264f84dbe7 100644 > --- a/builtin/add.c > +++ b/builtin/add.c > @@ -26,6 +26,7 @@ static const char * const

Re: Line ending normalization doesn't work as expected

Junio C Hamano writes: > Both this and its "git read-tree --empty" cousin share a grave > issue. The "git add ." step would mean that before doing these > commands, your working tree must be truly clean, i.e. the paths > in the filesystem known to the index must match what is

Re: Line ending normalization doesn't work as expected

Junio C Hamano wrote: > Jonathan Nieder writes: >> git checkout --renormalize . >> git status; # Show files that will be normalized >> git commit; # Commit the result >> >> What do you think? Would you be interested in writing a patch for it? >> ("No" is as

Re: Line ending normalization doesn't work as expected

Torsten Bögershausen writes: > One solution, which you can tell your team, is this one: > $ git rm -r --cached . && git add . Both this and its "git read-tree --empty" cousin share a grave issue. The "git add ." step would mean that before doing these commands, your working tree

Re: Line ending normalization doesn't work as expected

Jonathan Nieder writes: > I suspect what we are dancing around is the need for some command like > > git checkout --renormalize . > > which would shorten the sequence to > > git checkout --renormalize . > git status; # Show files that will be normalized >

Re: Line ending normalization doesn't work as expected

On Wed, Oct 04, 2017 at 11:26:55AM -0500, Robert Dailey wrote: > On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano wrote: > > Torsten Bögershausen writes: > > > >>> $ git rm -r --cached . && git add . > >> > >> (Both should work) > >> > >> To be honest, from the

Re: Line ending normalization doesn't work as expected

On Wed, Oct 4, 2017 at 11:59 AM, Jonathan Nieder wrote: > Hi Robert, > > Robert Dailey wrote: > >> You guys are obviously worlds ahead of me on the internals of things, >> but from my perspective I like to avoid the "plumbing" commands as >> much as I can. > > I suspect what

Re: Line ending normalization doesn't work as expected

Hi Robert, Robert Dailey wrote: > You guys are obviously worlds ahead of me on the internals of things, > but from my perspective I like to avoid the "plumbing" commands as > much as I can. I suspect what we are dancing around is the need for some command like git checkout

Re: Line ending normalization doesn't work as expected

On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano wrote: > Torsten Bögershausen writes: > >>> $ git rm -r --cached . && git add . >> >> (Both should work) >> >> To be honest, from the documentation, I can't figure out the difference >> between >> $ git read-tree

Re: Line ending normalization doesn't work as expected

Torsten Bögershausen writes: >> $ git rm -r --cached . && git add . > > (Both should work) > > To be honest, from the documentation, I can't figure out the difference > between > $ git read-tree --empty > and > $ git rm -r --cached . > > Does anybody remember the discussion, why

Re: Line ending normalization doesn't work as expected

On 2017-10-03 19:23, Robert Dailey wrote: > On Tue, Oct 3, 2017 at 11:26 AM, Torsten Bögershausen wrote: >> The short version is, that the instructions on Github are outdated. >> This is the official procedure (since 2016, Git v2.12 or so) >> But it should work even with older

Re: Line ending normalization doesn't work as expected

On Tue, Oct 3, 2017 at 11:26 AM, Torsten Bögershausen wrote: > The short version is, that the instructions on Github are outdated. > This is the official procedure (since 2016, Git v2.12 or so) > But it should work even with older version of Git. > > $ echo "* text=auto"

Re: Line ending normalization doesn't work as expected

On 2017-10-03 17:00, Robert Dailey wrote: > I'm on Windows using Git for Windows v2.13.1. Following github's > recommended process for fixing line endings after adding a > `.gitattributes` file[1], I run the following: > > $ rm .git/index && git reset > > Once I run `git status`, I see that no

Line ending normalization doesn't work as expected

I'm on Windows using Git for Windows v2.13.1. Following github's recommended process for fixing line endings after adding a `.gitattributes` file[1], I run the following: $ rm .git/index && git reset Once I run `git status`, I see that no files have changed. Note that I know for a fact in my