technical/shallow: describe why shallow cannot use replace refs
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@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:

committed by
Junio C Hamano

parent
8d0d81a9ca
commit
f42fa470b0
@ -17,6 +17,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
|
will be constructed, which has nr_parent < 0 to make it easier
|
||||||
to discern from user provided grafts.
|
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,
|
Since fsck-objects relies on the library to read the objects,
|
||||||
it honours shallow commits automatically.
|
it honours shallow commits automatically.
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user