Tomas Hajny schrieb:
> On Wed, April 8, 2009 16:22, Graeme Geldenhuys wrote:
>> On Wed, Apr 8, 2009 at 3:41 PM, Florian Klaempfl
>> wrote:
> .
> .
>> platforms as well. So far they are going a great job. BTW: I
>> understand FPC was Windows only in the beginning. ;-)
Windows support was very la
On Wed, April 8, 2009 16:22, Graeme Geldenhuys wrote:
> On Wed, Apr 8, 2009 at 3:41 PM, Florian Klaempfl
> wrote:
.
.
> platforms as well. So far they are going a great job. BTW: I
> understand FPC was Windows only in the beginning. ;-)
.
.
No, DOS. ;-)
Tomas
__
On Wed, Apr 8, 2009 at 3:41 PM, Florian Klaempfl wrote:
>
> As pascal shows, something proven is often better as some hype ;)
Good answer. :)
> exactly into my picture of git being a big design failure as a general
> purpose scm: besides being a posix hack (see also file names:
> ".gitattributes
Graeme Geldenhuys schrieb:
> hehe... OK, lets try this one more time...
>
> On Wed, Apr 8, 2009 at 2:12 PM, Florian Klaempfl
> wrote:
>>> In that case, all you would need is an editor that supports Unix line
>>> endings and not try and convert them to crlf as you edit the file -
>> Oh, maybe at
hehe... OK, lets try this one more time...
On Wed, Apr 8, 2009 at 2:12 PM, Florian Klaempfl wrote:
>> In that case, all you would need is an editor that supports Unix line
>> endings and not try and convert them to crlf as you edit the file -
>
> Oh, maybe at the end I should switch to linux to u
Graeme Geldenhuys schrieb:
> On Wed, Apr 8, 2009 at 1:18 PM, Marco van de Voort wrote:
>> That's not the same. Then you still have the mess of crlf mistakes in your
>> history.
>
> Well, if it's fixed in a later revision, then there is no problem. And
> even worse - if you submit a patch where ev
Graeme Geldenhuys schrieb:
> On Tue, Apr 7, 2009 at 8:46 PM, Florian Klaempfl
> wrote:
>> I know, but I don't want some crappy algorithm to guess if linefeed
>> conversion is needed or not, this feels so cvs like *g*
>
> In that case, all you would need is an editor that supports Unix line
> end
On Wed, Apr 8, 2009 at 1:18 PM, Marco van de Voort wrote:
>
> That's not the same. Then you still have the mess of crlf mistakes in your
> history.
Well, if it's fixed in a later revision, then there is no problem. And
even worse - if you submit a patch where every single line has changed
(due to
In our previous episode, Graeme Geldenhuys said:
[ Charset UTF-8 unsupported, converting... ]
> On Wed, Apr 8, 2009 at 1:00 PM, Marco van de Voort wrote:
> >> although I share Florian's concerns about "magic" detection of proper
> >> file type rather than combination of reasonably conservative and
On Wed, Apr 8, 2009 at 1:00 PM, Marco van de Voort wrote:
>> although I share Florian's concerns about "magic" detection of proper
>> file type rather than combination of reasonably conservative and obviously
>>...
>
> That also worried me a bit.
Well then you and Florian must have been worried f
In our previous episode, Tomas Hajny said:
> although I share Florian's concerns about "magic" detection of proper
> file type rather than combination of reasonably conservative and obviously
> configurable default setting combined with possibility to mark other files
> as plain text explicitly at
On Wed, April 8, 2009 12:33, Graeme Geldenhuys wrote:
> On Wed, Apr 8, 2009 at 12:26 PM, Tomas Hajny wrote:
.
.
>> I wouldn't be able to contribute any longer, because no (usable) Git
>> client for OS/2 / eCS exists at the moment as far as I know.
>
> Ignoring the fact that some exotic platforms
On Wed, Apr 8, 2009 at 12:26 PM, Tomas Hajny wrote:
> context of notes about great advantages of Git, not in the context of your
> announcement about fpGUI) that this is a limitation currently and that
Maybe a limitation for projects like FPC yes, but not for fpGUI. OS/2
(even though I loved it i
On Wed, April 8, 2009 11:58, Graeme Geldenhuys wrote:
> On Wed, Apr 8, 2009 at 11:48 AM, Tomas Hajny wrote:
>>>
>>
>> In this context, any editor which doesn't use LF by default (e.g. for
>> new
>> files) is not an option unless you require Unix users to use an editor
>> supporting CRLF as well or
On Wed, April 8, 2009 12:07, Graeme Geldenhuys wrote:
> On Wed, Apr 8, 2009 at 12:00 PM, Tomas Hajny wrote:
>>
>> I certainly don't want to discuss usefulness of git to individual users
>> or
>> projects, but it doesn't seem to be very fit to widely multi-platform
>> projects (yet) because much fe
On Wed, Apr 8, 2009 at 12:00 PM, Tomas Hajny wrote:
>
> I certainly don't want to discuss usefulness of git to individual users or
> projects, but it doesn't seem to be very fit to widely multi-platform
> projects (yet) because much fewer platforms are supported (directly or
> indirectly) at the m
On Wed, Apr 8, 2009 at 11:48 AM, Tomas Hajny wrote:
>>
>
> In this context, any editor which doesn't use LF by default (e.g. for new
> files) is not an option unless you require Unix users to use an editor
> supporting CRLF as well or unless you never expect non-Unix users to
> contribute to the p
On Tue, April 7, 2009 19:55, ik wrote:
.
.
> And there are even more features, but the question is if it good for all
> projects. I don't know the answer, I only know that I moved to git in my
> last new projects, and it helped me a lot when I was in a need to figure
> out
> when I destroy someth
On Wed, April 8, 2009 10:30, Graeme Geldenhuys wrote:
> On Tue, Apr 7, 2009 at 8:46 PM, Florian Klaempfl
> wrote:
>>
>> I know, but I don't want some crappy algorithm to guess if linefeed
>> conversion is needed or not, this feels so cvs like *g*
>
> In that case, all you would need is an editor t
On Tue, Apr 7, 2009 at 7:55 PM, ik wrote:
> Another better feature is the way tagging and brunching works. You can mix
> everything without making a copy of the whole tree all over on each
Yeah, that is great. Purely to play with git, I checkout out a very
old state (v0.4 of around mid 2007) of f
On Tue, Apr 7, 2009 at 8:46 PM, Florian Klaempfl wrote:
>
> I know, but I don't want some crappy algorithm to guess if linefeed
> conversion is needed or not, this feels so cvs like *g*
In that case, all you would need is an editor that supports Unix line
endings and not try and convert them to c
Another important factor about GIT, is that it's an offline version control.
Every person has their own repository, so you if the "online" repository
goes down, you have the ability to still properly work on things.
If you are working on a code that others works as well, no one hurt each
other as
> Out of interest, what version of Git are you using? Since v1.5.5
> (fairly old already) they defaulted the setting config.autocrlf = True
> under Windows.
I know, but I don't want some crappy algorithm to guess if linefeed
conversion is needed or not, this feels so cvs like *g*
Hi,
Has anybody thought of doing this or maybe done it already? I noticed
the Git help is written in plain text and uses asciidoc to generate
Unix ManPages, HTML, PDF, DocBook etc...
I guess in a way it's similar to LaTeX or wiki's. Plain text content
which gets used to generate various other fo
24 matches
Mail list logo
