From: Junio C Hamano <gitster@pobox.com>
To: "Samo Pogačnik via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, "Samo Pogačnik" <samo_pogacnik@t-2.net>,
"Patrick Steinhardt" <ps@pks.im>, "Taylor Blau" <me@ttaylorr.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH v2] shallow: set borders which are all reachable after clone shallow since
Date: Mon, 24 Nov 2025 16:43:33 -0800 [thread overview]
Message-ID: <xmqqh5ujuekq.fsf@gitster.g> (raw)
In-Reply-To: <pull.2107.v2.git.git.1763926552033.gitgitgadget@gmail.com> ("Samo Pogačnik via GitGitGadget"'s message of "Sun, 23 Nov 2025 19:35:52 +0000")
"Samo Pogačnik via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: =?UTF-8?q?Samo=20Poga=C4=8Dnik?= <samo_pogacnik@t-2.net>
>
> When shallow cloning based on a date, it happens that not all
> shallow border commits are reachable.
>
> Original implementation of a generic shallow boundary finder
> based on rev-list sets a commit (from the initial list of border
> commit candidates) to be the border commit as soon as it finds one
> of its parentis that wasn't on the list of initial candidates. This
> results in a successful shallow clone, where some of its declared
> border commits may not be reachable and they would not actually exist
> in the cloned repository. Thus the result may contradict existing
> comment in the code, which correctly states that such commmit should
> not be considered border.
>
> One can inspect such case by running the added test scenario:
> - 'clone shallow since all borders reachable'
>
> The modified implementation of a generic shallow boundary finder
> based on rev-list ensures that all shallow border commits are reachable
> also after being grafted. This is achieved by inspecting all parents
> of each initial border commit candidate. The border commit candidate
> is set border only when all its parents wern't on the initial list of
> candidates. Otherwise the border commit candidate is not set as border
> however its parents that weren't on the list of candidates are set as
> borders.
It is a minor point, but there are "boundary" and "border" used more
or less interchangeably in the proposed commit log message, and
would make the readers wonder if there are differences (I do not
think we use the word "border" anywhere in our documentation). It
is minor as we do not have such mixture in the end-user facing part
of the documentation with this patch.
I'll let those (cc'ed) who may be more familiar with, or, at least
have more code than I have in, the shallow infrastructure to comment
on the way the updated code uses the revision machinery.
Thanks.
> diff --git a/shallow.c b/shallow.c
> index 55b9cd9d3f..2929ac90ee 100644
> --- a/shallow.c
> +++ b/shallow.c
> @@ -251,21 +251,57 @@ struct commit_list *get_shallow_commits_by_rev_list(struct strvec *argv,
> * commit A is processed first, then commit B, whose parent is
> * A, later. If NOT_SHALLOW on A is cleared at step 1, B
> * itself is considered border at step 2, which is incorrect.
> + *
> + * We must also consider that B has multiple parents which may
> + * not all be marked NOT_SHALLOW (as they weren't traversed into
> + * the not_shallow_list from revs in the first place). Because of
> + * that an additional step is required to reconsider B as border.
> + * A commit from the not_shallow_list is considered border only
> + * when ALL its parents weren't on the not_shallow_list.
> + * When one or more parents of a commit from the not_shellow_list
> + * also come from that list, the commit is not considered border,
> + * but its non-listed parents are considered border commits.
> + *
> + * The general processing goes like this:
> + * 1. Above we've painted the whole not_shallow_list of commits
> + * NOT_SHALLOW.
> + * 2. For each commit from the not_shallow_list (the code below)
> + * we paint SHALLOW this commit and its parent for all its
> + * parents that had not yet been painted NOT_SHALLOW.
> + * 3. Commits with all parents being painted only SHALLOW remain
> + * shallow and are being added to result list.
> + * 4. Commits without all parents being painted only SHALLOW are
> + * being excluded as borders, however their parents painted only
> + * SHALLOW are being added to the result borders list.
> */
> for (p = not_shallow_list; p; p = p->next) {
> struct commit *c = p->item;
> struct commit_list *parent;
> + int must_not_be_shallow = 0;
>
> if (repo_parse_commit(the_repository, c))
> die("unable to parse commit %s",
> oid_to_hex(&c->object.oid));
>
> for (parent = c->parents; parent; parent = parent->next)
> - if (!(parent->item->object.flags & not_shallow_flag)) {
> + if (parent->item->object.flags & not_shallow_flag) {
> + must_not_be_shallow = 1;
> + } else {
> c->object.flags |= shallow_flag;
> - commit_list_insert(c, &result);
> - break;
> + parent->item->object.flags |= shallow_flag;
> }
> + if (must_not_be_shallow) {
> + c->object.flags &= ~shallow_flag;
> + for (parent = c->parents; parent; parent = parent->next)
> + if (parent->item->object.flags & shallow_flag) {
> + parent->item->object.flags |= not_shallow_flag;
> + commit_list_insert(parent->item, &result);
> + }
> + } else {
> + for (parent = c->parents; parent; parent = parent->next)
> + parent->item->object.flags &= ~shallow_flag;
> + commit_list_insert(c, &result);
> + }
> }
> free_commit_list(not_shallow_list);
>
> diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
> index 2677cd5faa..12209887fb 100755
> --- a/t/t5500-fetch-pack.sh
> +++ b/t/t5500-fetch-pack.sh
> @@ -904,6 +904,25 @@ test_expect_success 'shallow since with commit graph and already-seen commit' '
> )
> '
>
> +test_expect_success 'clone shallow since all borders reachable' '
> + test_create_repo shallow-since-all-borders-reachable &&
> + (
> + rm -rf shallow123 &&
> + cd shallow-since-all-borders-reachable &&
> + GIT_COMMITTER_DATE="2025-08-19 12:34:56" git commit --allow-empty -m one &&
> + GIT_COMMITTER_DATE="2025-08-20 12:34:56" git switch -c branch &&
> + GIT_COMMITTER_DATE="2025-08-21 12:34:56" git commit --allow-empty -m two &&
> + GIT_COMMITTER_DATE="2025-08-22 12:34:56" git commit --allow-empty -m three &&
> + GIT_COMMITTER_DATE="2025-08-23 12:34:56" git switch main &&
> + GIT_COMMITTER_DATE="2025-08-24 12:34:56" git merge branch --no-ff &&
> + GIT_COMMITTER_DATE="2025-08-26 12:34:56" git clone --shallow-since "2025-08-21 12:34:56" "file://$(pwd)/." ../shallow123 &&
> + cd ../shallow123 &&
> + echo "Shallow borders:" &&
> + cat .git/shallow &&
> + $(for commit in $(cat .git/shallow); do git rev-list $commit 1>/dev/null || exit 1; done)
> + )
> +'
> +
> test_expect_success 'shallow clone exclude tag two' '
> test_create_repo shallow-exclude &&
> (
>
> base-commit: debbc87557487aa9a8ed8a35367d17f8b4081c76
prev parent reply other threads:[~2025-11-25 0:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-22 10:38 [PATCH] Fixed --shallow-since generating descendant borders Samo Pogačnik via GitGitGadget
2025-11-22 17:36 ` Junio C Hamano
2025-11-23 19:35 ` [PATCH v2] shallow: set borders which are all reachable after clone shallow since Samo Pogačnik via GitGitGadget
2025-11-25 0:43 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh5ujuekq.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=me@ttaylorr.com \
--cc=ps@pks.im \
--cc=samo_pogacnik@t-2.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).