threads / discuss / 2396

ls-files and read-tree need core.filemode

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

## tl;dr

4 messages between Nov 8, 2005 and Nov 8, 2005.

replies: 3people: 3as markdown or json

Alex Riesen· Nov 8, 2005, 08:23 UTC · lore
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.
Junio C Hamano· Nov 8, 2005, 08:55 UTC · re: Alex Riesen · lore

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

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 ;-).

Show 5 quoted lines
>>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...

Alex Riesen· Nov 8, 2005, 09:39 UTC · re: Junio C Hamano · lore

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

On 11/8/05, Junio C Hamano <junkio@cox.net> wrote:
Show 5 quoted lines
> 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!
Show 10 quoted lines
> >>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.

Linus Torvalds· Nov 8, 2005, 18:15 UTC · re: Junio C Hamano · lore

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

On Tue, 8 Nov 2005, Junio C Hamano wrote:
Show 5 quoted lines
> 
> 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

← back to recent threads