On 18/10/17 02:40, Helen Borrie wrote:
>>From my dabblings with your test project yesterday, I think my
> problems are with the Git desktop, mostly. I don't like the UI much
> at all, although being able to connect from it to the source project
> is a nice feature, but not a life saver. When I ge
Hi Mark,
I used your repository for few Tests and further translation. I couldn't find
any problems. The Linux scripts are working and no strange behavior when I
create the html or pdf outputs.
>From my point of view everything is fine and it is much easier to add new
>contents (for me).
Rega
Mark Rotteveel wrote:
> Fixed in https://github.com/mrotteveel/test-firebird-documentation-4
I cloned this repository and built a number of targets, both in master and in
the B_Release branch.
Everything worked exactly as in my CVS checkout.
A number of source files in my (Windows) CVS working
Afternoon Paul,
On 18/10/17 14:08, Paul Vinkenoog wrote:
A number of source files in my (Windows) CVS working dir have Unix line endings
though, whereas their Git counterparts have DOS endings.
That's no problem, as long as it doesn't lead to a huge number of 'changes' and
log messages when
Hi Norman,
>> A number of source files in my (Windows) CVS working dir have Unix line
>> endings though, whereas their Git counterparts have DOS endings.
>>
>> That's no problem, as long as it doesn't lead to a huge number of 'changes'
>> and log messages when such a file is committed, clutterin
On 2017-10-18 15:08, Paul Vinkenoog wrote:
Mark Rotteveel wrote:
Fixed in https://github.com/mrotteveel/test-firebird-documentation-4
I cloned this repository and built a number of targets, both in master
and in the B_Release branch.
Everything worked exactly as in my CVS checkout.
A number
On 2017-10-18 15:35, Norman Dunbar wrote:
Afternoon Paul,
On 18/10/17 14:08, Paul Vinkenoog wrote:
A number of source files in my (Windows) CVS working dir have Unix
line endings though, whereas their Git counterparts have DOS endings.
That's no problem, as long as it doesn't lead to a huge
On 18/10/17 15:15, Mark Rotteveel wrote:
Given the normalization done during conversion, that should not be a
problem (unless a new file extension is introduced that isn't considered
a text file by the configuration of the conversion).
The thing I mentioned with autocrlf is the old way of doi
On 2017-10-18 16:45, Norman Dunbar wrote:
On 18/10/17 15:15, Mark Rotteveel wrote:
Given the normalization done during conversion, that should not be a
problem (unless a new file extension is introduced that isn't
considered a text file by the configuration of the conversion).
The thing I me
Thursday, October 19, 2017, 4:11:59 AM, Mark wrote:
> So if a new file extension for a text file would be introduced between
> now and the final conversion, then I would specifically need to take
> that into account, or we'll get a white space correction on the first
> commit that touches that f
10 matches
Mail list logo
