* Why did every line in w32fns.c get a ^M?
@ 2010-07-01 10:37 Lennart Borgman
2010-07-01 10:42 ` Juanma Barranquero
0 siblings, 1 reply; 10+ messages in thread
From: Lennart Borgman @ 2010-07-01 10:37 UTC (permalink / raw)
To: Emacs-Devel devel
When I just updated I got a merge conflict in w32fns.c. At the same
time all the lines in that file got a ^M at the end.
Why did they get that? (This is on w32.)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Why did every line in w32fns.c get a ^M?
2010-07-01 10:37 Why did every line in w32fns.c get a ^M? Lennart Borgman
@ 2010-07-01 10:42 ` Juanma Barranquero
2010-07-01 10:56 ` Lennart Borgman
0 siblings, 1 reply; 10+ messages in thread
From: Juanma Barranquero @ 2010-07-01 10:42 UTC (permalink / raw)
To: Lennart Borgman; +Cc: Emacs-Devel devel
On Thu, Jul 1, 2010 at 12:37, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> When I just updated I got a merge conflict in w32fns.c. At the same
> time all the lines in that file got a ^M at the end.
>
> Why did they get that? (This is on w32.)
Did you have local changes on w32fns.c? Perhaps you mixed CRLF vs LF.
Have you tried reverting the file?
Juanma
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Why did every line in w32fns.c get a ^M?
2010-07-01 10:42 ` Juanma Barranquero
@ 2010-07-01 10:56 ` Lennart Borgman
2010-07-01 11:00 ` Juanma Barranquero
0 siblings, 1 reply; 10+ messages in thread
From: Lennart Borgman @ 2010-07-01 10:56 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Emacs-Devel devel
On Thu, Jul 1, 2010 at 12:42 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 12:37, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
>> When I just updated I got a merge conflict in w32fns.c. At the same
>> time all the lines in that file got a ^M at the end.
>>
>> Why did they get that? (This is on w32.)
>
> Did you have local changes on w32fns.c? Perhaps you mixed CRLF vs LF.
> Have you tried reverting the file?
I have a lot of changes there, but I don't think there were any mix of
CRLF vs LF.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Why did every line in w32fns.c get a ^M?
2010-07-01 10:56 ` Lennart Borgman
@ 2010-07-01 11:00 ` Juanma Barranquero
2010-07-01 11:36 ` Lennart Borgman
0 siblings, 1 reply; 10+ messages in thread
From: Juanma Barranquero @ 2010-07-01 11:00 UTC (permalink / raw)
To: Lennart Borgman; +Cc: Emacs-Devel devel
On Thu, Jul 1, 2010 at 12:56, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> I have a lot of changes there, but I don't think there were any mix of
> CRLF vs LF.
The sudden appearance of ^M at the end of lines is an almost-100% sure
sign of such a mixup. When we're talking of a file that in a Bzr
checkout is LF, but it is often edited with CRLF-prone Windows tools,
the likelihood surpasses 100% :-)
So, please save your w32fns.c, revert it, and if it works, you know
the problem is in your changes... Certainly my w32fns.c has no trouble
whatsoever right now.
Juanma
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Why did every line in w32fns.c get a ^M?
2010-07-01 11:00 ` Juanma Barranquero
@ 2010-07-01 11:36 ` Lennart Borgman
2010-07-01 11:46 ` Juanma Barranquero
0 siblings, 1 reply; 10+ messages in thread
From: Lennart Borgman @ 2010-07-01 11:36 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Emacs-Devel devel
On Thu, Jul 1, 2010 at 1:00 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 12:56, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
>> I have a lot of changes there, but I don't think there were any mix of
>> CRLF vs LF.
>
> The sudden appearance of ^M at the end of lines is an almost-100% sure
> sign of such a mixup. When we're talking of a file that in a Bzr
> checkout is LF, but it is often edited with CRLF-prone Windows tools,
> the likelihood surpasses 100% :-)
The only tool I used editing it is Emacs ;-)
But it looks like w32fns.c somehow got saved with CRLF line endings (I
have no idea why) and it looks like bzr merge could not handle that at
all.
> So, please save your w32fns.c, revert it, and if it works, you know
> the problem is in your changes... Certainly my w32fns.c has no trouble
> whatsoever right now.
>
> Juanma
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Why did every line in w32fns.c get a ^M?
2010-07-01 11:36 ` Lennart Borgman
@ 2010-07-01 11:46 ` Juanma Barranquero
2010-07-01 12:56 ` Lennart Borgman
0 siblings, 1 reply; 10+ messages in thread
From: Juanma Barranquero @ 2010-07-01 11:46 UTC (permalink / raw)
To: Lennart Borgman; +Cc: Emacs-Devel devel
On Thu, Jul 1, 2010 at 13:36, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> But it looks like w32fns.c somehow got saved with CRLF line endings (I
> have no idea why)
I don't think it was Bazaar, so you're the likely culprit somehow... :-)
> and it looks like bzr merge could not handle that at all.
How could it? If the local copy suddenly has CRLF in every line, *all*
lines have changed and it has no anchors to detect where to apply
incoming changes.
Juanma
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Why did every line in w32fns.c get a ^M?
2010-07-01 11:46 ` Juanma Barranquero
@ 2010-07-01 12:56 ` Lennart Borgman
2010-07-01 17:03 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Lennart Borgman @ 2010-07-01 12:56 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Emacs-Devel devel
On Thu, Jul 1, 2010 at 1:46 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>
>> and it looks like bzr merge could not handle that at all.
>
> How could it? If the local copy suddenly has CRLF in every line, *all*
> lines have changed and it has no anchors to detect where to apply
> incoming changes.
You mean bzr can't be smart enough to recognize different line
endings? Of course not if it considers everything as binary, but that
is not necessary.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Why did every line in w32fns.c get a ^M?
2010-07-01 12:56 ` Lennart Borgman
@ 2010-07-01 17:03 ` Eli Zaretskii
2010-07-01 17:03 ` Lennart Borgman
2010-07-01 17:08 ` Juanma Barranquero
0 siblings, 2 replies; 10+ messages in thread
From: Eli Zaretskii @ 2010-07-01 17:03 UTC (permalink / raw)
To: Lennart Borgman; +Cc: lekktu, emacs-devel
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Thu, 1 Jul 2010 14:56:31 +0200
> Cc: Emacs-Devel devel <emacs-devel@gnu.org>
>
> On Thu, Jul 1, 2010 at 1:46 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> >
> >> and it looks like bzr merge could not handle that at all.
> >
> > How could it? If the local copy suddenly has CRLF in every line, *all*
> > lines have changed and it has no anchors to detect where to apply
> > incoming changes.
>
> You mean bzr can't be smart enough to recognize different line
> endings? Of course not if it considers everything as binary, but that
> is not necessary.
I actually think the default Bazaar operation regarding EOLs is very
nice. Even in your case, it did help you identify the problem right
away, didn't it?
But if you don't like the default and want to get yourself into more
trouble, read the section "End of Line Conversion" in the Bazaar User
Reference manual (in the "Concepts" chapter).
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Why did every line in w32fns.c get a ^M?
2010-07-01 17:03 ` Eli Zaretskii
@ 2010-07-01 17:03 ` Lennart Borgman
2010-07-01 17:08 ` Juanma Barranquero
1 sibling, 0 replies; 10+ messages in thread
From: Lennart Borgman @ 2010-07-01 17:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: lekktu, emacs-devel
On Thu, Jul 1, 2010 at 7:03 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Thu, 1 Jul 2010 14:56:31 +0200
>> Cc: Emacs-Devel devel <emacs-devel@gnu.org>
>>
>> On Thu, Jul 1, 2010 at 1:46 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>> >
>> >> and it looks like bzr merge could not handle that at all.
>> >
>> > How could it? If the local copy suddenly has CRLF in every line, *all*
>> > lines have changed and it has no anchors to detect where to apply
>> > incoming changes.
>>
>> You mean bzr can't be smart enough to recognize different line
>> endings? Of course not if it considers everything as binary, but that
>> is not necessary.
>
> I actually think the default Bazaar operation regarding EOLs is very
> nice. Even in your case, it did help you identify the problem right
> away, didn't it?
I think it is rather stupid actually.
It could have warned me of the situation instead.
> But if you don't like the default and want to get yourself into more
> trouble, read the section "End of Line Conversion" in the Bazaar User
> Reference manual (in the "Concepts" chapter).
Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Why did every line in w32fns.c get a ^M?
2010-07-01 17:03 ` Eli Zaretskii
2010-07-01 17:03 ` Lennart Borgman
@ 2010-07-01 17:08 ` Juanma Barranquero
1 sibling, 0 replies; 10+ messages in thread
From: Juanma Barranquero @ 2010-07-01 17:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lennart Borgman, emacs-devel
On Thu, Jul 1, 2010 at 19:03, Eli Zaretskii <eliz@gnu.org> wrote:
> Even in your case, it did help you identify the problem right
> away, didn't it?
Well, no, he first suspected of some general trouble afecting all users... ;-)
Juanma
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-07-01 17:08 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-01 10:37 Why did every line in w32fns.c get a ^M? Lennart Borgman
2010-07-01 10:42 ` Juanma Barranquero
2010-07-01 10:56 ` Lennart Borgman
2010-07-01 11:00 ` Juanma Barranquero
2010-07-01 11:36 ` Lennart Borgman
2010-07-01 11:46 ` Juanma Barranquero
2010-07-01 12:56 ` Lennart Borgman
2010-07-01 17:03 ` Eli Zaretskii
2010-07-01 17:03 ` Lennart Borgman
2010-07-01 17:08 ` Juanma Barranquero
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).