Retrieve specific commit from a remote Git repository

 

Is there any way to retrieve only one specific commit from a remote Git repo without cloning it on my PC? The structure of remote repo is absolutely same as that of mine and hence there won't be any conflicts but I have no idea how to do this and I don't want to clone that huge repository.

I am new to git, is there any way?

You only clone once, so if you already have a clone of the remote repository, pulling from it won't download everything again. Just indicate what branch you want to pull, or fetch the changes and checkout the commit you want.

Fetching from a new repository is very cheap in bandwidth, as it will only download the changes you don't have. Think in terms of Git making the right thing, with minimum load.

Git stores everything in .git folder. A commit can't be fetched and stored in isolation, it needs all its ancestors. They are interrelated.

To reduce download size you can however ask git to fetch only objects related to a specific branch or commit: 

git fetch origin refs/heads/branch:refs/remotes/origin/branch

This will download only commits contained in remote branch branch (and only the ones that you miss) , and store it in origin/branch . You can then merge or checkout.

You can also specify only a SHA1 commit: 

git fetch origin 96de5297df870:refs/remotes/origin/foo-commit

This will download only the commit of the specified SHA-1 96de5297df870 (and its ancestors that you miss), and store it as (non-existing) remote branch origin/foo-commit .

With Git 2.5+ (Q2 2015), fetching a single commit (without cloning the full repo) will actually be possible!

See commit 68ee628 by Fredrik Medley ( moroten ), 21 May 2015.
(Merged by Junio C Hamano -- gitster -- in commit a9d3493, 01 Jun 2015)

You now have a new config (on the server side) 

uploadpack.allowReachableSHA1InWant

Allow upload-pack to accept a fetch request that asks for an object that is reachable from any ref tip. However, note that calculating object reachability is computationally expensive.
Defaults to false .

With a combination of shallow clone ( git fetch --depth=1 ), you now can ask for a single commit (see t/t5516-fetch-push.sh : 

git fetch --depth=1 ../testrepo/.git $SHA1
git cat-file commit $SHA1

" git upload-pack " that serves " git fetch " can be told to serve commits that are not at the tip of any ref, as long as they are reachable from a ref, with uploadpack.allowReachableSHA1InWant configuration variable.

The full documentation is:

upload-pack : optionally allow fetching reachable sha1

With uploadpack.allowReachableSHA1InWant configuration option set on the server side, " git fetch " can make a request with a "want" line that names an object that has not been advertised (likely to have been obtained out of band or from a submodule pointer).
Only objects reachable from the branch tips, ie the union of advertised branches and branches hidden by transfer.hideRefs , will be processed.
Note that there is an associated cost of having to walk back the history to check the reachability.

This feature can be used when obtaining the content of a certain commit, for which the sha1 is known, without the need of cloning the whole repository, especially if a shallow fetch is used .

Useful cases are eg

  • repositories containing large files in the history,
  • fetching only the needed data for a submodule checkout,
  • when sharing a sha1 without telling which exact branch it belongs to and in Gerrit, if you think in terms of commits instead of change numbers.
    (The Gerrit case has already been solved through allowTipSHA1InWant as every Gerrit change has a ref.)

    • Git 2.6 (Q3 2015) will improve that model.
    See commit 2bc31d1, commit cc118a6 (28 Jul 2015) by Jeff King ( peff ).
    (Merged by Junio C Hamano -- gitster -- in commit 824a0be, 19 Aug 2015)

    refs : support negative transfer.hideRefs

    If you hide a hierarchy of refs using the transfer.hideRefs config, there is no way to later override that config to "unhide" it.
    This patch implements a "negative" hide which causes matches to immediately be marked as unhidden, even if another match would hide it.
    We take care to apply the matches in reverse-order from how they are fed to us by the config machinery, as that lets our usual "last one wins" config precedence work (and entries in .git/config , for example, will override /etc/gitconfig ).

    So you can now do: 

    git config --system transfer.hideRefs refs/secret
git config transfer.hideRefs '!refs/secret/not-so-secret'

    to hide refs/secret in all repos, except for one public bit in one specific repo.

    Git 2.7 (Nov/Dec 2015) will improve again:

    See commit 948bfa2, commit 00b293e (05 Nov 2015), commit 78a766a, commit 92cab49, commit 92cab49, commit 92cab49 (03 Nov 2015), commit 00b293e, commit 00b293e (05 Nov 2015), and commit 92cab49, commit 92cab49, commit 92cab49, commit 92cab49 (03 Nov 2015) by Lukas Fleischer ( lfos ).
    Helped-by: Eric Sunshine ( sunshineco ).
    (Merged by Jeff King -- peff -- in commit dbba85e, 20 Nov 2015)

    config.txt : document the semantics of hideRefs with namespaces

    Right now, there is no clear definition of how transfer.hideRefs should behave when a namespace is set.
    Explain that hideRefs prefixes match stripped names in that case. This is how hideRefs patterns are currently handled in receive-pack.

    hideRefs: add support for matching full refs

    In addition to matching stripped refs, one can now add hideRefs patterns that the full (unstripped) ref is matched against.
    To distinguish between stripped and full matches, those new patterns must be prefixed with a circumflex ( ^ ).

    Hence the new documentation: 

    transfer.hideRefs:

    If a namespace is in use, the namespace prefix is stripped from each reference before it is matched against transfer.hiderefs patterns.
    For example, if refs/heads/master is specified in transfer.hideRefs and the current namespace is foo , then refs/namespaces/foo/refs/heads/master is omitted from the advertisements but refs/heads/master and refs/namespaces/bar/refs/heads/master are still advertised as so-called "have" lines.
    In order to match refs before stripping, add a ^ in front of the ref name. If you combine ! and ^ , ! must be specified first.

    I did a pull on my git repo: 

    git pull --rebase <repo> <branch>

    Allowing git to pull in all the code for the branch and then I went to do a reset over to the commit that interested me.

    git reset --hard <commit-hash>

    Hope this helps.

    链接地址: http://www.djcxy.com/p/90448.html

    上一篇: 在Git中，origin / master vs origin master有什么区别？

    下一篇: 从远程Git存储库中检索特定的提交