It is tempting to do away with commit_graft altogether (in the long haul), now that grafts are deprecated. However, the shallow feature needs a couple of things that the replace refs cannot fulfill. Let's point that out in the documentation. Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> --- By the way, I did not squash this into the previous patch on purpose: in my mind, describing the relationship with replace refs is different enough from pointing out from the goal of this here patch to merit a separate commit. And that goal is: to describe why "shallow" cannot be implemented on top of "replace refs". Documentation/technical/shallow.txt | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt index b3ff23c25f6..cb79181c2bb 100644 --- a/Documentation/technical/shallow.txt +++ b/Documentation/technical/shallow.txt @@ -25,6 +25,13 @@ Each line contains exactly one SHA-1. When read, a commit_graft will be constructed, which has nr_parent < 0 to make it easier to discern from user provided grafts. +Note that the shallow feature could not be changed easily to +use replace refs: a commit containing a `mergetag` is not allowed +to be replaced, not even by a root commit. Such a commit can be +made shallow, though. Also, having a `shallow` file explicitly +listing all the commits made shallow makes it a *lot* easier to +do shallow-specific things such as to deepen the history. + Since fsck-objects relies on the library to read the objects, it honours shallow commits automatically. -- 2.17.0.windows.1.4.g7e4058d72e3
