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 that
>> this causes file modes to rese
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 Git. Is there a way to
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 then added afresh to t
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 figure out the difference
>>> between
>>> $ git read-tree -
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 --empty
>> and
>> $ git rm -r --cach
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 term, rather then
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 "renormalize" at all.
> 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 built
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 in the
> index (mod
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 always an acceptable an
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 must be truly c
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
> git commit; # Com
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 documentation, I can't figure out the
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 we are dancing around
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 --renormalize
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 --empty
>> and
>> $ git rm -r --cach
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 we ended up with
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 version of Git.
>>
>
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" >.gitattributes
> $ git re
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 fi
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 repo
21 matches
Mail list logo