8 research outputs found

    Attendance and number of Software Carpentry workshops January 2012 - January 2014

    No full text
    <p>Enrollment data: Cumulative number of people enrolled for each Software Carpentry workshop where attendance numbers were noted. N.B. Enrolment figures are somewhat imprecise: individuals that attended on day 1 but not day 2 were included, while those that attended without registration were not included. Hopefully these two effects more or less cancel out and should should not detract from the overall trend displayed.</p> <p>Workshop data: Dates of all Software Carpentry workshops held to date.</p

    Ten simple rules for making research software more robust

    No full text
    <div><p>Software produced for research, published and otherwise, suffers from a number of common problems that make it difficult or impossible to run outside the original institution or even off the primary developer’s computer. We present ten simple rules to make such software robust enough to be run by anyone, anywhere, and thereby delight your users and collaborators.</p></div

    Resources.

    No full text
    <p>Resources.</p

    The git add/commit process.

    No full text
    <p>To store a snapshot of changes in your repository, first git add any files to the staging area you wish to commit (for example, you’ve updated the process.sh file). Second, type git commit with a message. Only files added to the staging area will be committed. All past commits are located in the hidden .git directory in your repository.</p

    Working with a local repository.

    No full text
    <p>(A) To designate a directory on your computer as a Git repo, type the command git init. This initializes the repository and will allow you to track the files located within that directory. (B) Once you have added a file, follow the git add/commit cycle to place the new file first into the staging area by typing git add to designate it to be committed, and then git commit to take the shapshot of that file. The commit is assigned a commit identifier (d75es) that can be used in the future to pull up this version or to compare different committed versions of this file. (C) As you continue to add and change files, you should regularly add and commit those changes. Here, an additional commit was done, and the commit log now shows two commit identifiers: d75es (from step B) and f658t (the new commit). Each commit will generate a unique identifier, which can be examined in reverse chronological order using git log.</p

    Contributing to open source projects.

    No full text
    <p>We would like you to add an empty file that is named after your GitHub username to the repo used to write this manuscript. (A) Using your internet browser, navigate to <a href="https://github.com/jdblischak/git-for-science" target="_blank">https://github.com/jdblischak/git-for-science</a>. (B) Click on the “Fork” button to create a copy of this repo on GitHub under your username. (C) On your computer, type git clone <a href="https://github.com/username/git-for-science.git" target="_blank">https://github.com/username/git-for-science.git</a>, which will create a copy of git-for-science on your local machine. (D) Navigate to the readers directory by typing cd git-for-science/readers/. Create an empty file that is titled with your GitHub username by typing touch username.txt. Commit that new file by adding it to the staging area (git add username.txt) and committing with a message (git commit -m "Add username to directory of readers."). Note that your commit identifier will be different than what is shown here. (E) You have committed your new file locally, and the next step is to push that new commit up to the git-for-science repo under your username on GitHub. To do so, type git push origin master. (F) To request to add your commits to the original git-for-science repo, issue a pull request from the git-for-science repo under your username on GitHub. Once your Pull Request is reviewed and accepted, you will be able to see the file you committed with your username in the original git-for-science repository.</p

    Working with both a local and remote repository as a single user.

    No full text
    <p>(A) On your computer, you commit to a Git repository (commit d75es). (B) On GitHub, you create a new repository called thesis. This repository is currently empty and not linked to the repo on your local machine. (C) The command git remote add connects your local repository to your remote repository. The remote repository is still empty, however, because you have not pushed any content to it. (D) You send all the local commits to the remote repository using the command git push. Only files that have been committed will appear in the remote repository. (E) You repeat several more rounds of updating scripts and committing on your local computer (commit f658t and then commit xv871). You have not yet pushed these commits to the remote repository, so only the previously pushed commit is in the remote repo (commit d75es). (F) To bring the remote repository up to date with your local repository, you git push the two new commits to the remote repository. The local and remote repositories now contain the same files and commit histories.</p
    corecore