git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Samo Pogačnik via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: "Samo Pogačnik" <samo_pogacnik@t-2.net>,
	"Samo Pogačnik" <samo_pogacnik@t-2.net>
Subject: [PATCH v2] shallow: set borders which are all reachable after clone shallow since
Date: Sun, 23 Nov 2025 19:35:52 +0000	[thread overview]
Message-ID: <pull.2107.v2.git.git.1763926552033.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.2107.git.git.1763807914242.gitgitgadget@gmail.com>

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.

Signed-off-by: Samo Pogačnik <samo_pogacnik@t-2.net>
---
    Fixed --shallow-since generating descendant borders
    
    When shallow cloning based on a date, it happens that a list of commits
    is received, where some of the list border commits actually descend one
    from another. In such cases borders need to be expanded by additional
    parents and excluding the child as border.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2107%2Fspog%2Ffix-shallow-since-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2107/spog/fix-shallow-since-v2
Pull-Request: https://github.com/git/git/pull/2107

Range-diff vs v1:

 1:  aaeff44f83 ! 1:  479692c386 Fixed --shallow-since generating descendant borders
     @@ Metadata
      Author: Samo Pogačnik <samo_pogacnik@t-2.net>
      
       ## Commit message ##
     -    Fixed --shallow-since generating descendant borders
     +    shallow: set borders which are all reachable after clone shallow since
      
     -    When shallow cloning based on a date, it happens that a list
     -    of commits is received, where some of the list border commits
     -    actually descend one from another. In such cases borders need
     -    to be expanded by additional parents and excluding the child
     -    as border.
     +    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.
      
          Signed-off-by: Samo Pogačnik <samo_pogacnik@t-2.net>
      
     @@ shallow.c: struct commit_list *get_shallow_commits_by_rev_list(struct strvec *ar
       	 * 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, some of
     -+	 * them not being in the not_shallow_list, but must be added
     -+	 * as border commits to the result.
     ++	 *
     ++	 * 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 coloured the whole not_shallow_list of commits
     -+	 *    with 'not_shallow'.
     ++	 * 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 colour 'shallow' the commit and its parents, which are not
     -+	 *    already coloured 'not_shallow'.
     -+	 * 3. Commits with all parents being coloured only 'shallow' remain
     ++	 *    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 coloured only 'shallow' are
     -+	 *    being excluded as borders, however their parents coloured only
     -+	 *    'shallow' are being added to the result borders 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;
     @@ shallow.c: struct commit_list *get_shallow_commits_by_rev_list(struct strvec *ar
       	}
       	free_commit_list(not_shallow_list);
       
     +
     + ## t/t5500-fetch-pack.sh ##
     +@@ t/t5500-fetch-pack.sh: 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 &&
     + 	(


 shallow.c             | 42 +++++++++++++++++++++++++++++++++++++++---
 t/t5500-fetch-pack.sh | 19 +++++++++++++++++++
 2 files changed, 58 insertions(+), 3 deletions(-)

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
-- 
gitgitgadget

  parent reply	other threads:[~2025-11-23 19:35 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 ` Samo Pogačnik via GitGitGadget [this message]
2025-11-25  0:43   ` [PATCH v2] shallow: set borders which are all reachable after clone shallow since Junio C Hamano

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=pull.2107.v2.git.git.1763926552033.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=git@vger.kernel.org \
    --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).