Menu
There are a number of git commands, such as git clone --depth 10 <repo>, that require the number of revisions [git help revisions] to be given.
What is the distinction between a commit and a revision (in git, rather than say svn)?
Or does it only show up in the plural when trying to count revisions/commits, e.g. that revisons must be counted by walking the DAG (directed acyclic graph) of commits and their parents, or some other careful distinction?
733
– Git commits are local meaning they are recorded only on the machine on which the commits actually occur. The “git commit” command is used to tell Git to save your changes to the local repository and you have to specifically tell Git which changes you wish to include in a commit before using the “git commit” command.
Commits are the core building block units of a Git project timeline. Commits can be thought of as snapshots or milestones along the timeline of a Git project. Commits are created with the git commit command to capture the state of a project at that point in time.
For example, if you are on the branch blabla, then @{1} means the same as blabla@{1}. The special construct @{-} means the th branch checked out before the current one. A suffix ^ to a revision parameter means the first parent of that commit object. ^ means the th parent (i.e. rev^ is equivalent to rev^1).
Other than that there are no revision numbers in git. You'll have to tag commits yourself if you want more user-friendliness. Show activity on this post. I'd just like to note another possible approach - and that is by using git git-notes(1), in existence since v 1.6.
See "SPECIFYING REVISIONS" of git rev-parse:
A revision parameter
<rev>typically, but not necessarily, names a commit object.
It uses what is called an extended SHA1 syntax, [and includes] various ways to spell object names.
So "revision" refers to the id you can use as a parameter to reference an object in git (usually a commit).
HEAD@{5 minutes ago} is a revision which reference the commit present 5 minutes ago.
gitrevision mentions:
[...] some Git commands (such as
git show) also take revision parameters which denote other objects than commits, e.g. blobs ("files") or trees ("directories of files").
For instance, the following rev parameter doesn't reference a commit:
<rev>:<path>, e.g. HEAD:README, :README, master:./README A suffix
:followed by a path names the blob or tree at the given path in the tree-ish object named by the part before the colon.
A "commit" in Git generally designates a "commit object" (as described in git commit-tree for instance):
A commit encapsulates:
- all parent object ids
- author name, email and date
- committer name and email and the commit time.
So:
In your case (git clone) --depth <n> does:
Create a shallow clone with a history truncated to the specified number of revisions.
It is for all the commits accessible at that depth, up to n revisions per path in the DAG.
Since the result can be more than n commits, the term revision is more adapted here in order to emphasize you don't want just n commits, but any commits referenced by a max of n revisions accessible.
However, in this context, revisions clearly reference only commits (as illustrated below) reachable (as you mentioned in "Is git clone --depth 1 (shallow clone) more useful than it makes out?").
The question is "reachable from what"?
You referenced this thread which included:
IIRC,
--depth=<n>is not "deepen by<n>", but "make sure I have at least<n>from the updated tip(s)".
The shallow-clone hack gives you quite useless (even though it may be internally consistent) semantics if you shallow-cloned way in the past and fetched with--depthafter the other side added many more commits than<n>, as you cannot guess what the right value of<n>should be without actually fetching without--depth.
111
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
