threads / discuss / 63988

git: list of my complaints about future graft removal

Subject: git: list of my complaints about future graft removal

## tl;dr

4 messages between Aug 19, 2025 and Aug 25, 2025.

replies: 3people: 3as markdown or json

Askar Safin· Aug 19, 2025, 13:57 UTC · lore
Hi.

I just have read in https://github.com/git/git/blob/v2.51.0/Documentation/BreakingChanges.adoc that git grafts will be removed in git 3.0.

Let me share my list of complaints/objections/thoughts about this.
(And also some info for kernel.org admins.)
* As well as I understand, Linux history repo
( https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/ )
relies on grafts. It is supposed that whoever clones that repo,
should manually graft latest commit of history repo with earliest commit
of main Linux history. Also that person should graft two other commits of history
repo (as well as I understand).

So, git and/or kernel.org people, please, ensure that this history repo will continue to work after removal of grafts.

Also, currently this is very hard to discover how to get full Linux history. If we type "how to get unified linux kernel git history" to Google, we will get this answer: https://stackoverflow.com/a/8130239 , which also points to this link: https://archive.org/details/git-history-of-linux .

Both these links rely on grafts. So, please, make sure that whoever types "how to get unified linux kernel git history" into Google will get modern instructions in top links, which do not rely on grafts.

Again: I strongly think that we should not remove graft support
until https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/
is made compatible with "git replace".
history.git is valuable repo, and I think a lot of people use history.git .

Git release notes for 3.0 should mention how to get history.git working without grafts.

* As well as I understand, "git clone --depth=1" rely on grafts, too.
I hope "git clone --depth=1" will continue to work.

-- Askar Safin https://types.pl/@safinaskar

Bagas Sanjaya· Aug 20, 2025, 14:11 UTC · re: Askar Safin · lore

Re: git: list of my complaints about future graft removal

On Tue, Aug 19, 2025 at 05:57:08PM +0400, Askar Safin wrote:
> * As well as I understand, "git clone --depth=1" rely on grafts, too.
> I hope "git clone --depth=1" will continue to work.

So shallow clones should use git-replace(1) under the hood (both on initial clone, deepening with --shallow-since and --unshallow), right?

Thanks.
-- 
An old man doll... just what I always wanted! - Clara
Askar Safin· Aug 25, 2025, 13:39 UTC · re: Bagas Sanjaya · lore

Re: git: list of my complaints about future graft removal

 ---- On Wed, 20 Aug 2025 18:11:30 +0400  Bagas Sanjaya <bagasdotme@gmail.com> wrote --- 
 > So shallow clones should use git-replace(1) under the hood (both on initial
 > clone, deepening with --shallow-since and --unshallow), right?
You are asking me? I'm not git developer.
What you mean? How git works currently or how it should work in 3.0?
I don't know how it works currently.
And I don't know how it will work in the future.

I just want "git clone --depth=1" to continue to work. I. e. git developers should somehow take measures to make sure "git clone --depth=1" will continue to work even if grafts will be removed.

Currently "git clone --depth=1" seems to be implemented using grafts, i. e. I see word "grafted" in "git log" output if I use "git clone --depth=1" (I just tested this on git 2.47.2)

-- Askar Safin https://types.pl/@safinaskar

Junio C Hamano· Aug 25, 2025, 23:36 UTC · re: Bagas Sanjaya · lore

Re: git: list of my complaints about future graft removal

Bagas Sanjaya <bagasdotme@gmail.com> writes:
Show 6 quoted lines
> On Tue, Aug 19, 2025 at 05:57:08PM +0400, Askar Safin wrote:
>> * As well as I understand, "git clone --depth=1" rely on grafts, too.
>> I hope "git clone --depth=1" will continue to work.
>
> So shallow clones should use git-replace(1) under the hood (both on initial
> clone, deepening with --shallow-since and --unshallow), right?

An unfortunate historical glitch is that shallow uses neither the grafts (which is being removed) nor replace but its own mechanism. It internally borrows the same "graft" code paths but the data is stored outside the normal grafts mechanism, if I understand correctly.

← back to recent threads