0

I'm following a tutorial for learning rails (and I'm still kind of new to git). I know how to revert back to a local version 

>>git log -p
>>git revert <sha1> //the sha1 to return to

Lets say I don't have local access anymore to the file but I have remote access to the repository, how would I clone into a specific version?

Pardeep Dhingra
  • 3,916
  • 7
  • 30
  • 56
ForRealzzzz
  • 5
  • 1
  • 2
    Possible duplicate of [How to clone git repository with specific revision/changeset?](http://stackoverflow.com/questions/3489173/how-to-clone-git-repository-with-specific-revision-changeset) – Viktor Oct 27 '16 at 14:54
  • 1
    The `git revert` command *backs out* the given commit (makes a new commit that consists of "remove whatever was added, add whatever was removed"). (In Mercurial it's actually spelled `hg backout`, which is probably less confusing.) You most likely want to just check out the specific commit. – torek Oct 27 '16 at 17:47

2 Answers2

0
$ git clone $URL
$ cd $PROJECT_NAME
$ git reset --hard $SHA1
Viktor
  • 4,218
  • 4
  • 32
  • 63
  • It looks like you copied this from your linked answer. Unfortunately, it's correct only for Git versions before 1.7 or so. – torek Oct 27 '16 at 17:48
  • ... Addendum: or, with the server side configuration item I mention in the other answer. – torek Oct 27 '16 at 18:15
-1

The easiest way is to clone the whole repository, then check out the specific revision of interest. With large repositories, that may be expensive. You can sometimes reduce the cost by doing a "shallow" clone, but you will need to know how deep to go and whether there is a reference that is "close to" your desired hash.

You may or may not be allowed to retrieve one specific commit, as a tarball or zip archive, through git archive --remote. The constraint is up to the server, as described in the git upload-archive documentation:

SECURITY

In order to protect the privacy of objects that have been removed from history but may not yet have been pruned, git-upload-archive avoids serving archives for commits and trees that are not reachable from the repository’s refs. However, because calculating object reachability is computationally expensive, git-upload-archive implements a stricter but easier-to-check set of rules:

  1. Clients may request a commit or tree that is pointed to directly by a ref. E.g., git archive --remote=origin v1.0.

  2. Clients may request a sub-tree within a commit or tree using the ref:path syntax. E.g., git archive --remote=origin v1.0:Documentation.

  3. Clients may not use other sha1 expressions, even if the end result is reachable. E.g., neither a relative commit like master^ nor a literal sha1 like abcd1234 is allowed, even if the result is reachable from the refs.

Note that rule 3 disallows many cases that do not have any privacy implications. These rules are subject to change in future versions of git, and the server accessed by git archive --remote may or may not follow these exact rules.

If the config option uploadArchive.allowUnreachable is true, these rules are ignored, and clients may use arbitrary sha1 expressions. This is useful if you do not care about the privacy of unreachable objects, or if your object database is already publicly available for access via non-smart-http.

For this same security reason, you cannot in general clone or fetch by hash ID in modern versions of Git. Site like GitHub that allow direct access to a commit by hash ID are doing so by working "around" Git, rather than through Git. But:

Not mentioned in the quote above is uploadpack.allowReachableSHA1InWant, which if enabled restores the old Git 1.5 style ability to fetch by hash (computationally expensively, on the server). This was new in Git 2.5. See Retrieve specific commit from a remote Git repository. Again, this must be enabled on the server.

Community
  • 1
  • 1
torek
  • 448,244
  • 59
  • 642
  • 775