How to clone git repository with specific revision/changeset?

How can I clone git repository with specific revision, something like I usually do in Mercurial:

hg clone -r 3 /path/to/repository

  • GIT: determine revision based on a file
  • Why does Git display certain new folders when checking out old revisions?
  • Git svn fetch retrieving only one revision at a time
  • Is there a way to use Git to flag code for future review?
  • Svn2git: Add revision number to git commit title
  • How to list files in specific revision in `git`?
  • SVN: Is it possible to get the list of revision numbers for given path?
  • Files have different revision numbers in Eclipse (Subversion)
  • 10 Solutions collect form web for “How to clone git repository with specific revision/changeset?”

    UPDATE for git versions > 1.7 use git clone and git reset, as described in Vaibhav Bajpai’s answer

    If you don’t want to fetch the full repository then you probably shouldn’t be using clone. You can always just use fetch to choose the branch that you want to fetch. I’m not an hg expert so I don’t know the details of -r but in git you can do something like this.

    # make a new blank repository in the current directory
    git init
    # add a remote
    git remote add origin url://to/source/repository
    # fetch a commit (or branch or tag) of interest
    # Note: the full history of this commit will be retrieved
    git fetch origin <sha1-of-commit-of-interest>
    # reset this repository's master branch to the commit of interest
    git reset --hard FETCH_HEAD
    $ git clone $URL
    $ cd $PROJECT_NAME
    $ git reset --hard $SHA1

    To again go back to the most recent commit

    $ git pull

    Cloning a git repository, aptly, clones the entire repository: there isn’t a way to select only one revision to clone. However, once you perform git clone, you can checkout a specific revision by doing checkout <rev>.

    If you mean you want to fetch everything from the beginning up to a particular point, Charles Bailey’s answer is perfect. If you want to do the reverse and retrieve a subset of the history going back from the current date, you can use git clone --depth [N] where N is the number of revs of history you want. However:


    Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.

    Just to sum things up (git v.

    1. do a regular git clone where you want the repo (gets everything to date — I know, not what is wanted, we’re getting there)
    2. git checkout <sha1 rev> of the rev you want
    3. git reset --hard
    4. git checkout -b master

    TL;DR – Just create a tag in the source repository against the commit you want to clone up to and use the tag in the fetch command. You can delete the tag from the original repo later to clean up.

    Well, its 2014 and it looks like Charles Bailey’s accepted answer from 2010 is well and truly outdated by now and most (all?) of the other answers involve cloning, which many people are hoping to avoid.

    The following solution achieves what the OP and many others are looking for, which is a way to create a copy of a repository, including history, but only up to a certain commit.

    Here are the commands I used with git version 2.1.2 to clone a local repo (ie. a repository in another directory) up to a certain point:

    # in the source repository, create a tag against the commit you want to check out
    git tag -m "Temporary tag" tmptag <sha1>
    # create a new directory and change into that directory
    cd somewhere_else;mkdir newdir;cd newdir
    # ...and create a new repository
    git init
    # add the source repository as a remote (this can be a URL or a directory)
    git remote add origin /path/to/original/repo
    # fetch the tag, which will include the entire repo and history up to that point
    git fetch origin refs/tags/tmptag
    # reset the head of the repository
    git reset --hard FETCH_HEAD
    # you can now change back to the original repository and remove the temporary tag
    cd original_repo
    git tag -d tmptag

    Hopefully this solution keeps working for a few more years! 🙂

    Using 2 of the above answers (How to clone git repository with specific revision/changeset? and How to clone git repository with specific revision/changeset?)
    Helped me to come up with a definative. If you want to clone up to a point, then that point has to be a tag/branch not simply an SHA or the FETCH_HEAD gets confused. Following the git fetch set, if you use a branch or tag name, you get a response, if you simply use an SHA-1 you get not response.
    Here’s what I did:-
    create a full working clone of the full repo, from the actual origin

    cd <path to create repo>
    git clone git@<our gitlab server>:ui-developers/ui.git 

    Then create a local branch, at the point that’s interesting

    git checkout 2050c8829c67f04b0db81e6247bb589c950afb14
    git checkout -b origin_point

    Then create my new blank repo, with my local copy as its origin

    cd <path to create repo>
    mkdir reduced-repo
    cd reduced-repo
    git init
    git remote add local_copy <path to create repo>/ui
    git fetch local_copy origin_point

    At that point I got this response. I note it because if you use a SHA-1 in place of the branch above, nothing happens, so the response, means it worked

    /var/www/html/ui-hacking$ git fetch local_copy origin_point
    remote: Counting objects: 45493, done.
    remote: Compressing objects: 100% (15928/15928), done.
    remote: Total 45493 (delta 27508), reused 45387 (delta 27463)
    Receiving objects: 100% (45493/45493), 53.64 MiB | 50.59 MiB/s, done.
    Resolving deltas: 100% (27508/27508), done.
    From /var/www/html/ui
     * branch            origin_point -> FETCH_HEAD
     * [new branch]      origin_point -> origin/origin_point

    Now in my case, I then needed to put that back onto gitlab, as a fresh repo so I did

    git remote add origin git@<our gitlab server>:ui-developers/new-ui.git

    Which meant I could rebuild my repo from the origin_point by using git --git-dir=../ui/.git format-patch -k -1 --stdout <sha1> | git am -3 -k to cherry pick remotely then use git push origin to upload the whole lot back to its new home.

    Hope that helps someone

    My version was a combination of accepted and most upvoted answers. But it’s a little bit different, because everyone uses SHA1 but nobody tells you how to get it

    $ git init
    $ git remote add <remote_url>
    $ git fetch --all

    now you can see all branches & commits

    $ git branch -a
    $ git log remotes/origin/master <-- or any other branch

    Finally you know SHA1 of desired commit

    git reset --hard <sha1>

    You Can use simply git check <commit hash>

    in this sequence

    git clone URLTORepository

    git checkout commithash

    commit hash looks like this “45ef55ac20ce2389c9180658fdba35f4a663d204”

    git clone -o <sha1-of-the-commit> <repository-url> <local-dir-name>

    git uses the word origin in stead of popularly known revision

    Following is a snippet from the manual $ git help clone

    --origin <name>, -o <name>
        Instead of using the remote name origin to keep track of the upstream repository, use <name>.
    Git Baby is a git and github fan, let's start git clone.