This worked for me in cmd:

git clone git://github.com/D-Programming-Language/druntime.git

I have TortoiseGit installed.


/Jacob Carlborg

On 24 jan 2011, at 09:11, Don Clugston wrote:

> On 24 January 2011 04:32, Jason Evans <jasone at canonware.com> wrote:
>> On 01/23/2011 06:57 PM, Andrei Alexandrescu wrote:
>>> 
>>> Say I have a change to make to one file in phobos 2 to get started. Could you please summarize what steps I need to take?
>> 
>> Let's suppose we want to update the README.txt in druntime, which currently refers to dsource.org.  First we need a git repository to work in.  Take a look at the following web page to get the appropriate ssh location.
>> 
>>  https://github.com/D-Programming-Language/druntime
>> 
>> Clone the repository.
>> 
>>  $ git clone git at github.com:D-Programming-Language/druntime.git
> 
> Worth noting that on Windows, you *must* be in the git bash shell. If
> you try this from the windows command prompt you get:
> Initialized empty Git repository in
> /cygdrive/c/dmd2dev/src/gitdmd/druntime/.git/
> fatal: exec ssh failed.
> fatal: The remote end hung up unexpectedly
> 
> BTW: Thanks Jason,  I think this will be a great step forward for D.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

In this case you are checking out a read-only copy for which you don't need a key pair. Anyway, the usual practice is to fork the repository and make pull requests. As I said I don't know how the organization thing works, but I assume if you are listed as a member you can commit as the organization, but maybe I am wrong.

On Mon, Jan 24, 2011 at 10:04 AM, Jacob Carlborg <doob at me.com> wrote:
> This worked for me in cmd:
>
> git clone git://github.com/D-Programming-Language/druntime.git
>
> I have TortoiseGit installed.

I believe the HTTPS link allows write access as well.  The SSH version is simply preferred.

On Jan 24, 2011, at 10:29 AM, Jesse Phillips wrote:

> In this case you are checking out a read-only copy for which you don't need a key pair. Anyway, the usual practice is to fork the repository and make pull requests. As I said I don't know how the organization thing works, but I assume if you are listed as a member you can commit as the organization, but maybe I am wrong.
> 
> On Mon, Jan 24, 2011 at 10:04 AM, Jacob Carlborg <doob at me.com> wrote:
>> This worked for me in cmd:
>> 
>> git clone git://github.com/D-Programming-Language/druntime.git
>> 
>> I have TortoiseGit installed.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Mon, Jan 24, 2011 at 10:39 AM, Sean Kelly <sean at invisibleduck.org> wrote:
> I believe the HTTPS link allows write access as well. ?The SSH version is simply preferred.

You are still required to have a key pair when committing to GitHub, there is no password.

Read-Only: git://github.com/he-the-great/JPDLibs.git
HTTPS: https://he-the-great at github.com/he-the-great/JPDLibs.git
Git: git at github.com:he-the-great/JPDLibs.git

This is how the URLs are formatted for each one, as you can see the read-only version uses git and my username is a folder. Anyway, it should all work with any terminal/console you desire.

On Jan 23, 2011, at 7:32 PM, Jason Evans wrote:

> On 01/23/2011 06:57 PM, Andrei Alexandrescu wrote:
>> Say I have a change to make to one file in phobos 2 to get started. Could you please summarize what steps I need to take?
> 
> Let's suppose we want to update the README.txt in druntime, which currently refers to dsource.org.  First we need a git repository to work in.  Take a look at the following web page to get the appropriate ssh location.

From other discussion, it looks like there are two possible workflows.  The one that you describe is the more SVN-like in that all operations are ultimately push/pull against the origin master.  The second seems to involve use of the github web page to create a fork, and a commit to the origin master seems to involve a pull request.  I can see the use of the latter approach when working on something requiring discussion or review, and am wondering what the standard dev model should be.

On 24 January 2011 18:55, Jesse Phillips <jesse.k.phillips at gmail.com> wrote:
> On Mon, Jan 24, 2011 at 12:11 AM, Don Clugston <dclugston at googlemail.com> wrote:
>> On 24 January 2011 04:32, Jason Evans <jasone at canonware.com>
>>> Clone the repository.
>>>
>>> ?$ git clone git at github.com:D-Programming-Language/druntime.git
>>
>> Worth noting that on Windows, you *must* be in the git bash shell. If
>> you try this from the windows command prompt you get:
>> Initialized empty Git repository in
>> /cygdrive/c/dmd2dev/src/gitdmd/druntime/.git/
>> fatal: exec ssh failed.
>> fatal: The remote end hung up unexpectedly
>
> There shouldn't be any issue with using cmd or powershell. My guess is that an RSA was not generated, or you don't have your public key activated in your profile. I'm not exactly sure how this works with organizations, but this page should help:
>
> http://help.github.com/msysgit-key-setup/

No. It just plain doesn't work from cmd. It works fine from git bash. Probably, it's just a path issue -- but the error message is dreadful.

However, git for Windows seems to be on about the same level of development as 64-bit DMD. "It works" -- but only provided your standards are very low. Trying to roll back a branch to an older version of DMD, I got this beauty of an error message:
---------------------
error: bad index file sha1 signature
fatal: index file corrupt
error: bad index file sha1 signature
fatal: index file corrupt
error: bad index file sha1 signature
fatal: index file corrupt
error: bad index file sha1 signature
fatal: index file corrupt
error: bad index file sha1 signature
fatal: index file corrupt
Cannot save the current index state
---------------------
Well, I must have done something wrong, but the punishment seems a little excessive. Is there some way to recreate the index file? Maybe TortoiseGit does something to the paths to allow the command line to work correctly.

Sean Kelly wrote:
> In SVN you can set eol-style to native, and it converts line endings when the repos is retrieved, I believe.  Maybe we'll just have to standardize on \n?
>
>
> 

Standardize on \n

Here's a simple program to do it (tolf.d):

/* Replace line endings with LF
 */

import std.file;
import std.path;

int main(string[] args)
{
    foreach (f; args[1 .. $])
    {
        auto input = cast(char[]) std.file.read(f);
        auto output = filter(input);
        if (output != input)
            std.file.write(f, output);
    }
    return 0;
}


char[] filter(char[] input)
{
    char[] output;
    size_t j;

    for (size_t i = 0; i < input.length; i++)
    {
        auto c = input[i];

        switch (c)
        {
            case '\r':
                c = '\n';
                break;

            case '\n':
                if (i && input[i - 1] == '\r')
                    continue;
                break;

            case 0:
                continue;

            default:
                break;
        }
        output ~= c;
        j++;
    }
    return output[0 .. j];
}

Yes, I'm sure it can be done in linux with a 1 line script, but my
linux-fu is weak :-(
Here's it's companion program detab.d that I use before checkins:


/* Replace tabs with spaces, and remove trailing whitespace from lines.
 */

import std.file;
import std.path;

int main(string[] args)
{
    foreach (f; args[1 .. $])
    {
        auto input = cast(char[]) std.file.read(f);
        auto output = filter(input);
        if (output != input)
            std.file.write(f, output);
    }
    return 0;
}


char[] filter(char[] input)
{
    char[] output;
    size_t j;

    int column;
    for (size_t i = 0; i < input.length; i++)
    {
        auto c = input[i];

        switch (c)
        {
            case '\t':
                while ((column & 7) != 7)
                {   output ~= ' ';
                    j++;
                    column++;
                }
                c = ' ';
                column++;
                break;

            case '\r':
            case '\n':
                while (j && output[j - 1] == ' ')
                    j--;
                output = output[0 .. j];
                column = 0;
                break;

            default:
                column++;
                break;
        }
        output ~= c;
        j++;
    }
    while (j && output[j - 1] == ' ')
        j--;
    return output[0 .. j];
}

Jens Mueller wrote:
> I'll guess not. Because
> core.autocrlf = true means
> "Use this setting if you want to have CRLF line endings in your working
> directory even though the repository does not have normalized line endings."
> (see man git-config)
>
> See here for further explanation: http://stackoverflow.com/questions/3206843/how-line-ending-conversions-work-with-git-core-autocrlf-between-different-operati
>
> The part "Moving forward" on github seems rather strange to me.
>
> 

I tried various settings a few months back, and failed miserably. Nobody I asked could tell me what the various settings actually did, none of the online explanations made any sense (*). My takeaway was:

1. do not attempt to use git on Windows
2. write tolf.d and fix all line endings to \n before submission to git

So far, that works.


(*) First off, there were several settings. Nobody could tell me if git stored the files in its database with canonicalized line endings, what happened to the original files (were they modified by git?) and what happens when files were restored from git (line endings left as is, rewritten, what?), if only the diff programs affected, was the sha hash affected, etc.

Clearly, at a deep fundamental level, git works with binary files. Not text files. Attempting to hammer it to work with text files is just doomed.

>> There shouldn't be any issue with using cmd or powershell. My guess is that an RSA was not generated, or you don't have your public key activated in your profile. I'm not exactly sure how this works with organizations, but this page should help:
>>
>> http://help.github.com/msysgit-key-setup/
>
> No. It just plain doesn't work from cmd. It works fine from git bash. Probably, it's just a path issue -- but the error message is dreadful.

I guess what I should have said is that I tested it with my own GitHub repository and had no issue. I do not disagree that the error only occurs with cmd, but I don't think everyone will have this issue (I'm on 32bit XP, so maybe that has something to do with it).

> However, git for Windows seems to be on about the same level of development as 64-bit DMD. "It works" -- but only provided your standards are very low. Trying to roll back a branch to an older version of DMD, I got this beauty of an error message:

I haven't put git through a large number of its features. Anyway, this is what I got for a suggestion:

$ rm -f .git/index
$ git reset

http://stackoverflow.com/questions/1115854/index-file-corrupt

Don't know if it works but I can't exactly test it.

Le 2011-01-24 ? 15:28, Walter Bright a ?crit :

> (*) First off, there were several settings. Nobody could tell me if git stored the files in its database with canonicalized line endings, what happened to the original files (were they modified by git?) and what happens when files were restored from git (line endings left as is, rewritten, what?), if only the diff programs affected, was the sha hash affected, etc.
> 
> Clearly, at a deep fundamental level, git works with binary files. Not text files. Attempting to hammer it to work with text files is just doomed.

I worked a lot with Git on Windows (through Cygwin) with no problem. But I never ever activated the line ending conversion option. It's not the first time I hear it causes problems. My recommendation is to make sure git does not try to convert the line endings and let your editor handle whatever comes in. The worse that can happen is that line endings get mixed up, which is pretty much the same as tabs and spaces being mixed up, which can be solved using the same solutions.

My biggest complain goes to those who made that Windows Git installer. They should have abstained from making the newline conversion the default.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/