ls-files and read-tree need core.filemode

ls-files and read-tree need core.filemode

[Alex Riesen]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

Hi,

ls-files.c and read-tree.c miss the default configuration, in
particular the filemode=false part.
The recent +x bit flip made me notice that, because git-merge refused
to merge anything saying that git-pull.sh is not up to date.

As usual, sorry for attachments.

[-- Attachment #2: ls-files-filemode.patch --]
[-- Type: application/xxxxx, Size: 426 bytes --]

[-- Attachment #3: read-tree-filemode.patch --]
[-- Type: application/xxxxx, Size: 452 bytes --]

Re: ls-files and read-tree need core.filemode

[Junio C Hamano]

Alex Riesen <raa.lkml@gmail.com> writes:

> As usual, sorry for attachments.

Attachments are a bit cumbersome to quote but otherwise OK, at
least for me.  Linus never admits it, but I am hoping that he is
having a bit easier time applying e-mailed patches ever since
rudimentally MIME attachment handling was added.

However, please note that git-mailinfo which splits a piece of
e-mail into metainformation and patch part takes commit log
material only from the main message part, so having this
one-line explanation inside attachment is like having it under
the three-dash line.

>>    ls-files needs default config to ignore filemode on cygwin

I think this case you meant to do that; your main message part
was almost fine as is, as a commit log message (except perhaps
the initial "Hi," part ;-).

>>diff --git a/ls-files.c b/ls-files.c
>>--- a/ls-files.c
>>+++ b/ls-files.c
>>@@ -569,10 +569,11 @@ int main(int argc, const char **argv)
>> 	argv0 = *argv;

I wonder what this thing is, though.  I sense that usage()
cleanup patch that makes programs state their names
semi-automatically is coming...

Re: ls-files and read-tree need core.filemode

[Alex Riesen]

On 11/8/05, Junio C Hamano <junkio@cox.net> wrote:
> However, please note that git-mailinfo which splits a piece of
> e-mail into metainformation and patch part takes commit log
> material only from the main message part, so having this
> one-line explanation inside attachment is like having it under
> the three-dash line.

Noted, thanks!

> >>diff --git a/ls-files.c b/ls-files.c
> >>--- a/ls-files.c
> >>+++ b/ls-files.c
> >>@@ -569,10 +569,11 @@ int main(int argc, const char **argv)
> >>      argv0 = *argv;
>
> I wonder what this thing is, though.  I sense that usage()
> cleanup patch that makes programs state their names
> semi-automatically is coming...
>

That's just me, trying to figure out were all the errors were coming from.
Promise to try to base patches properly in the future.

Re: ls-files and read-tree need core.filemode

[Linus Torvalds]

On Tue, 8 Nov 2005, Junio C Hamano wrote:
> 
> Attachments are a bit cumbersome to quote but otherwise OK, at
> least for me.  Linus never admits it, but I am hoping that he is
> having a bit easier time applying e-mailed patches ever since
> rudimentally MIME attachment handling was added.

Actually, the MIME attachment support in git means that I have to remove 
the "Content-Type: .. boundary: " line too when editing emails. 

I do all my patch validation in mbox format (which is why when you look at 
commit dates, you'll generally see a second or less between commits when I 
actually apply a mbox series), and the MIME format makes emails totally 
unreadable.

So I refuse to have anything to do with attachments and MIME types not 
because my tools couldn't apply the patches, but because I can't go 
through the patches manually sanely with them.

So I can do plain/text attachments, but they inevitably mean that I just 
have to edit the damn mailbox to make sense of it. Anything else (like 
base64-encoding or similar) I just refuse to touch.

			Linus