Getting history without checking out

Question

For a project I need to know all commits between two revisions.

Normally one would just clone the repository and check the history. I don't need the files to be actually present on the filesystem, I'm only intersted in the history itself.
Due to the nature of large repositories, cloning them can take some time.

Is there a way to only get the history (or even the history between two revisions) in minimal time? Is it possible to actually not to check out the files (because I guess thats it what's taking the most time).

If you have local access to a public repo you can do a `git log` or `gitk` there. No need to clone the repo. — EncryptedWatermelon, May 10 '19 at 12:59
If you have a ssh access to the server where the git repo is, you could try to run the `git log`command through ssh. (see https://stackoverflow.com/a/1178586/3393195) — Gruntzy, May 10 '19 at 13:14

score 5 · Accepted Answer · answered May 10 '19 at 13:22

The keywords here are "shallow clone".

Checking out a given revision can be rather long in itself, but this is not the longest operation while cloning a repository, since all objects will be repatriated first before a given revision is checked out.

You may want, however, to take a look at the --depth and --shallow-since parameters of git clone, which will allow you to fetch only the tips of the branches until a given point.

This will let you quickly retrieve the most recent history of a given repository, which is probably what you need the most, then use git fetch again to repatriate the rest of a branch if needed.

Retrieving the sole history in itself is unfortunately not possible (as far as I know) since this history is not "recorded" as a whole in some kind of file but constituted by the recursive references of each object to its fathers one.

So, something really dirty you could do if you had an access (even read-only) to the .git original subdirectory is to copy all files located under .git/objects but only the ones which are known to be commit (you can tell it with git cat-file -t). The thing would be broken in itself because neither the trees nor the files themselves would be available at the time you do, but you would still be able to fetch them with a git remote update or similar operation.

score 4 · Answer 2 · answered May 10 '19 at 12:59

4

Use --bare for your cloning operation, you'll have a git repo with no worktree (actual files) but whole history available to inspect.

answered May 10 '19 at 12:59

Romain Valeri

19,645
3
36
61

1

Unfortunately, this won't make the repository be quicker to download. All objects will still be repatriated. Only the `checkout` after full repository rebuild will be skipped. – Obsidian May 10 '19 at 13:08
I'll check the actual time difference, but I'm afraid that's the only possibility. – hellow May 10 '19 at 13:08
1

@Obsidian That's correct. The "only" expected benefit here is to avoid a potentially long checkout operation in itself (can occur on big enough repos). – Romain Valeri May 10 '19 at 13:18

Getting history without checking out

2 Answers2