Skip to content

Check for remote url instead of .git existence#2102

Closed
hmtheboy154 wants to merge 1 commit into
tiann:mainfrom
hmtheboy154:makefile_git
Closed

Check for remote url instead of .git existence#2102
hmtheboy154 wants to merge 1 commit into
tiann:mainfrom
hmtheboy154:makefile_git

Conversation

@hmtheboy154

@hmtheboy154 hmtheboy154 commented Sep 30, 2024

Copy link
Copy Markdown
Contributor

Current implementation of .git checking have some issues:

  • If a kernel source being cloned using git-repo tool, especially newer version, it will clone .git in .repo inside of the submodule source.
  • Newer kernel source changed how $(src) & $(srctree) output. In the case of kernel 6.11 as I tested $(src) show the relative path of the symlink in drivers/ instead of KernelSU main directory. Which makes checking for ../.git existence completely useless.

One idea I would like to propose is to check for the remote URL in $(src). If the remote is correct then we can assume this is KSU repo and then count the version (also unshallow the repo). Here's what I did:

  • Check if kernel is 6.9+ and then change $(src) accordingly.
  • Print $(src) remote in verbose and check for the correct URL (both ssh & https).
  • If correct, check if the repo is shallow by using git rev-parse --is-shallow-repository. Unshallow if it's return true.
  • Calculate version as usual.

The only drawback I can see so far is that forks will have to edit the url in the Makefile, which I don't think it's much of an issue.

Current implementation of .git checking have some issues:
- If a kernel source being cloned using git-repo tool, especially
newer version, it will clone .git in .repo inside of the submodule
source.
- Newer kernel source changed how $(src) & $(srctree) output. In
the case of kernel 6.11 as I tested $(src) show the relative path
of the symlink in drivers/ instead of KernelSU main directory.
Which makes checking for ../.git existence comletely useless.

One idea I would like to propose is to check for the remote URL in
$(src). If the remote is correct then we can assume this is
KSU repo and then count the version (also unshallow the repo).
Here's what I did:
- Check if kernel is 6.9+ and then change $(src) accordingly.
- Print $(src) remote in verbose and check for the correct
 URL (both ssh & https).
- If correct, check if the repo is shallow by using
git rev-parse --is-shallow-repository. Unshallow if it's return true.
- Calculate version as usual.

The only drawback I can see so far is that forks will have to edit
the url in the Makefile, which I don't think it's much of an issue.

Signed-off-by: hmtheboy154 <buingoc67@gmail.com>
@hmtheboy154 hmtheboy154 mentioned this pull request Oct 14, 2024
rsuntk pushed a commit to rsuntk/KernelSU that referenced this pull request Oct 19, 2025
Current implementation of .git checking have some issues:
- If a kernel source being cloned using git-repo tool, especially
newer version, it will clone .git in .repo inside of the submodule
source.
- Newer kernel source changed how $(src) & $(srctree) output. In
the case of kernel 6.11 as I tested $(src) show the relative path
of the symlink in drivers/ instead of KernelSU main directory.
Which makes checking for ../.git existence comletely useless.

One idea I would like to propose is to check for the remote URL in
$(src). If the remote is correct then we can assume this is
KSU repo and then count the version (also unshallow the repo).
Here's what I did:
- Check if kernel is 6.9+ and then change $(src) accordingly.
- Print $(src) remote in verbose and check for the correct
 URL (both ssh & https).
- If correct, check if the repo is shallow by using
git rev-parse --is-shallow-repository. Unshallow if it's return true.
- Calculate version as usual.

The only drawback I can see so far is that forks will have to edit
the url in the Makefile, which I don't think it's much of an issue.

* Unmerged PR:
tiann#2102

Signed-off-by: hmtheboy154 <buingoc67@gmail.com>
Signed-off-by: Faris <rsuntk@yukiprjkt.my.id>
@dabao1955

Copy link
Copy Markdown
Contributor

see #3108?

@hmtheboy154

Copy link
Copy Markdown
Contributor Author

see #3108?

yea looks better, I'll close this one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants