在Git中，如何从远程存储库中签出或更新到最新版本？

Question

I'd like to create a simple script that clones a Github repository, updates the repository's working directory to the latest revision whichever branch it may be on , and then runs its tests.

To do this in Mercurial, I could use the following steps:

hg clone https://hghub.com/user/my-repo my-repo
cd my-repo
hg update tip

What is the Git equivalent to hg update tip ?

Answer 1

There isn't one. In Mercurial, the "tip" is simply the highest numbered revision (using the relative rev numbers, which works there because commits are always "added to the pile", as it were).

(That is, there's an absolute numbering of commits in any given repo . However, when two different repos that had diverged, are re-synchronized, the relative numbers of particular commits may not match up. For instance, suppose Joe and I start by each "hg clone"-ing a repo with 6 commits. I commit a change as rev 7, and it's ready to go out, but before I push, Joe commits a change as his rev 7 and pushes to our shared central repo. Now I pull his change, which is my rev 8; I merge my 7 and 8 and make commit 9; I push my 7-and-9 to the central repo, where they become revs 8 and 9 respectively. [Nothing happens with my rev 8, which the central repo already has as commit 7.] I now have as my rev 8, the changeset that is Joe's-and-central-repo's rev 7; and I have rev 9 as the merge. If he now pulls my change and merge, he has my change as his rev 8, and the merge as 9. So the relative numbers don't match any more at this point. But when you make your initial clone, this does not matter: yo u're copying the other repo, and in the process you copy its numbering too.)

If you can get hold of the other side's git reflogs (in this case, the branch history on github), you could look at which branch was most recently stepped-forward. That would represent the latest commit. Or, it's possible that github tracks these things and allows everyone access to them (I don't know enough about github to say).

(You could also look at commit time stamps, but again they're not necessarily in the order that commits were added to the repository.)

Answer 2

As torek said, there isn't a built-in way, because that's not how git works.

However, you can roll your own method, somewhat, though it's a bit involved.

You could go with a naive approach, which lists all commits in <commit time> <full hash> style, sorts them numerically ( %ct is commit times in Unix epoch format, which is number of seconds since the start of 1970, so they sort nicely), takes the last one, cuts out just the hash, and checks that out:

$ git checkout `git log --all --format='%ct %H' | sort -n | tail -1 | cut -d' ' -f2`

However, that leaves you in a detached head state, because you're checking out by hash, and not by reference.

A slightly less naive, and longer approach would be to get all the known branches, which is to say the branch heads, and run those through a similar process, cutting out the branch ref at the end and checking that out:

$ git checkout $(for b in `git br | sed 's/..//'`; do echo `git log -1 $b --format='%ct %H'` $b; done | sort -n | tail -1 | cut -d' ' -f3)

There could be edge cases, but I don't know them. The commit times should be in a good order, because everything that creates a commit, be it commit , cherry-pick , rebase , commit --amend , etc., all update the commit time of the commit they're copying. In other words, you can't insert an out-of-order date into the middle of a branch. If you cherry-pick something onto a branch, it goes on top with the latest commit time. If you rebase, each commit is made in sequence from the bottom up, so they'll also be in order.

That said, rebase operations often create commits at a greater than 1-per-second intervals, in which case you'll have commits with exactly the same commit time, and it doesn't get any more fine-grained than that (I sometimes wish it did), so it's quite possible that the sort operation here will mix up the order of commits with matching timestamps. You could try to use author times at that point to help work things out, but that starts to become a more complicated function, and no longer a fairly straightforward shell pipeline. Also, I'm not sure how correct that would always be. There could be crazy edge cases.