2009/5/13 Hugo Mildenberger [off-list ref]:
Am Mittwoch, 13. Mai 2009 schrieb Alex Riesen [off-list ref]
quoted
That'd mean to loose the information completely. Which is just as bad
as putting the LF in the url in the first place.
This stray linefeed is not information, but pure contamination. Thus it
would be much better to simply strip it off.
Not at the place where the patch changes it. In git clone, maybe (the many
times mentioned guessing function). But then, we have to provide an option
to leave the names alone, verbatim (which, I think, the non-quessing form
already provides. No additional coding necessary).
And besides from the fact that git apply rejects this patch (fatal: corrupt
patch at line 6),
This is your local problem. Maybe you copied the patch through clipboard
and it kept the presentation in KMail, or KMail generally corrupts
mails, I don't
know. Just save the mail as is and do "git am -3" on it.
I think it would also not handle the equally wrong repository directory name on disk,
You think wrong. It does handle it perfectly.
And it is not wrong. It is just how it is. Don't spend too much time in MacOS
and that overgrown DOS. They'll wreck your brain.
which then possibly leads to subsequent make failures (as it actually happend in
the case I described earlier here.)
The make(1) works in such directories just fine. Fix yours (thinking about
it now - you wont find a make which does not work in such directories).
Why not just return to your original idea, which proposed testing the
repository name against a regular expression describing a forbidden
set of characters (which is "\n", currently) and then terminate with a
clear message?
The idea was not abandoned nor followed upon. It's just I don't need that
warning and would switch it off immediately anyway (if it was implemented).
I just spent a minute thinking about it (that's where regexp idea came from).
I'm not going to work on it (at least, not right now). I'm even sure you wont
be working on it too, now when you have learned what the problem is and
how to work around it. And that's while all you needed is to put a two-three
lines in that guessing function...
Am Mittwoch, 13. Mai 2009 schrieb Alex Riesen:
2009/5/13 Hugo Mildenberger [off-list ref]:
quoted
Am Mittwoch, 13. Mai 2009 schrieb Alex Riesen [off-list ref]
quoted
That'd mean to loose the information completely. Which is just as bad
as putting the LF in the url in the first place.
This stray linefeed is not information, but pure contamination. Thus it
would be much better to simply strip it off.
Not at the place where the patch changes it. In git clone, maybe (the many
times mentioned guessing function). But then, we have to provide an option
to leave the names alone, verbatim (which, I think, the non-quessing form
already provides. No additional coding necessary).
quoted
And besides from the fact that git apply rejects this patch (fatal: corrupt
patch at line 6),
This is your local problem. Maybe you copied the patch through clipboard
and it kept the presentation in KMail, or KMail generally corrupts
mails, I don't
know. Just save the mail as is and do "git am -3" on it.
My apologies, the problem actually was copy & paste from kmail.
quoted
I think it would also not handle the equally wrong repository directory name on disk,
You think wrong. It does handle it perfectly.
I'm thinking right. The stray linefeed is still there:
ls -l 'bluetooth-testing.git
'/ -d
drwxr-xr-x 23 hm hm 4096 13. Mai 15:06 bluetooth-testing.git?/
quoted
which then possibly leads to subsequent make failures (as it actually happend in
the case I described earlier here.)
The make(1) works in such directories just fine. Fix yours (thinking about
it now - you wont find a make which does not work in such directories).
You aren't saying which make you are using, but GNU make version 3.81 or
the linux kernel make system still can't cope with a linefeed contaminated directory
name:
hm@localhost /var/tmp/bluetooth-testing.git $ make
make[1]: /mnt/hda1/tmp/bluetooth-testing.git: No such file or directory
make[1]: *** No rule to make target `/mnt/hda1/tmp/bluetooth-testing.git'. Stop.
make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop.
quoted
Why not just return to your original idea, which proposed testing the
repository name against a regular expression describing a forbidden
set of characters (which is "\n", currently) and then terminate with a
clear message?
The idea was not abandoned nor followed upon. It's just I don't need that
warning and would switch it off immediately anyway (if it was implemented).
I just spent a minute thinking about it (that's where regexp idea came from).
I'm not going to work on it (at least, not right now). I'm even sure you wont
be working on it too, now when you have learned what the problem is and
how to work around it. And that's while all you needed is to put a two-three
lines in that guessing function...
I reported this problem here after I already knew the cause and how to avoid
the problem, because I thought it might be useful fix it generally, especially
useful for those who run git within a brushwood of scripts, which I do not.
If you personally would need this or not is not of so much interest here. But
I was interested in discussing a clean way to implement it.