2019-08-30 14:20:29 +02:00
|
|
|
#!/usr/bin/env python3
|
2023-08-15 16:20:26 +02:00
|
|
|
# SPDX-FileCopyrightText: 2019-2023 Blender Authors
|
2023-06-14 15:06:58 +02:00
|
|
|
#
|
2022-02-11 04:30:11 +01:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
|
|
|
|
"""
|
|
|
|
Utility functions for make update and make tests.
|
|
|
|
"""
|
2019-08-30 14:20:29 +02:00
|
|
|
|
2019-08-29 11:13:41 +02:00
|
|
|
import re
|
Make update: Show Git LFS download progress
Solves the issue of the script potentially sitting for a long time
without having any progress reported. Confusingly, such behavior
depends on Git version.
In older versions (< 2.33) there will be progress reported, but it
then got changed by the commit in Git:
https://github.com/git/git/commit/7a132c628e57b9bceeb88832ea051395c0637b16
The delayed checkout is exactly how Git LFS integrates into the Git
process. Another affecting factor for the behavior is that submodule
configured to use "checkout" update policy is forced to have quite
flag passed to the "git checkout":
https://github.com/git/git/blob/v2.43.2/builtin/submodule--helper.c#L2258
This is done to avoid the long message at the end of checkout about
the detached state of HEAD, with instructions how to resolve that.
There are two possible solutions: either use "rebase" update policy
for submodules, or skip Git LFS download during the submodule update.
Changing the update policy is possible, but it needs to be done with
a bit of care, and possible revised process for updating/merging
tests data.
This change follows the second idea of delaying LFS download for a
later step, so the process is the following:
- Run `git submodule update`, but tell Git LFS to not resolve the links
by using GIT_LFS_SKIP_SMUDGE=1 environment variable.
- Run `git lfs pull` for the submodule, to resolve the links.
Doing so bypasses hardcoded silencing in the Git. It also potentially
allows to recover from an aborted download process.
The `git lfs pull` seems to be a nominal step to resolve the LFS links
after the smudging has been skipped. It is also how in earlier Git
versions some Windows limitations were bypassed:
https://www.mankier.com/7/git-lfs-faq
The submodule update now also receives the "--progress" flag, which
logs the initial Git repository checkout process, which further
improves the feedback.
The byproduct of this change is that an error during precompiled
libraries and tests data update is not considered to be fatal.
It seems to be more fitting with other update steps, and allows
more easily reuse some code.
There is also a cosmetic change: the messages at the end of the
update process now have their own header, allowing more easily
see them in the wall-of-text.
Pull Request: https://projects.blender.org/blender/blender/pulls/118673
2024-02-23 17:40:59 +01:00
|
|
|
import os
|
2019-09-30 10:19:55 +02:00
|
|
|
import shutil
|
2019-08-30 14:20:29 +02:00
|
|
|
import subprocess
|
|
|
|
import sys
|
2022-09-15 18:08:15 +02:00
|
|
|
from pathlib import Path
|
2019-08-30 14:20:29 +02:00
|
|
|
|
2022-09-16 02:49:49 +02:00
|
|
|
from typing import (
|
2024-02-28 01:02:53 +01:00
|
|
|
Dict,
|
2022-09-16 02:49:49 +02:00
|
|
|
Sequence,
|
|
|
|
Optional,
|
|
|
|
)
|
2020-10-02 02:10:01 +02:00
|
|
|
|
2022-09-16 02:49:49 +02:00
|
|
|
|
2024-02-28 01:02:53 +01:00
|
|
|
def call(
|
|
|
|
cmd: Sequence[str],
|
|
|
|
exit_on_error: bool = True,
|
|
|
|
silent: bool = False,
|
|
|
|
env: Optional[Dict[str, str]] = None,
|
|
|
|
) -> int:
|
2021-09-20 13:17:01 +02:00
|
|
|
if not silent:
|
Make update: Show Git LFS download progress
Solves the issue of the script potentially sitting for a long time
without having any progress reported. Confusingly, such behavior
depends on Git version.
In older versions (< 2.33) there will be progress reported, but it
then got changed by the commit in Git:
https://github.com/git/git/commit/7a132c628e57b9bceeb88832ea051395c0637b16
The delayed checkout is exactly how Git LFS integrates into the Git
process. Another affecting factor for the behavior is that submodule
configured to use "checkout" update policy is forced to have quite
flag passed to the "git checkout":
https://github.com/git/git/blob/v2.43.2/builtin/submodule--helper.c#L2258
This is done to avoid the long message at the end of checkout about
the detached state of HEAD, with instructions how to resolve that.
There are two possible solutions: either use "rebase" update policy
for submodules, or skip Git LFS download during the submodule update.
Changing the update policy is possible, but it needs to be done with
a bit of care, and possible revised process for updating/merging
tests data.
This change follows the second idea of delaying LFS download for a
later step, so the process is the following:
- Run `git submodule update`, but tell Git LFS to not resolve the links
by using GIT_LFS_SKIP_SMUDGE=1 environment variable.
- Run `git lfs pull` for the submodule, to resolve the links.
Doing so bypasses hardcoded silencing in the Git. It also potentially
allows to recover from an aborted download process.
The `git lfs pull` seems to be a nominal step to resolve the LFS links
after the smudging has been skipped. It is also how in earlier Git
versions some Windows limitations were bypassed:
https://www.mankier.com/7/git-lfs-faq
The submodule update now also receives the "--progress" flag, which
logs the initial Git repository checkout process, which further
improves the feedback.
The byproduct of this change is that an error during precompiled
libraries and tests data update is not considered to be fatal.
It seems to be more fitting with other update steps, and allows
more easily reuse some code.
There is also a cosmetic change: the messages at the end of the
update process now have their own header, allowing more easily
see them in the wall-of-text.
Pull Request: https://projects.blender.org/blender/blender/pulls/118673
2024-02-23 17:40:59 +01:00
|
|
|
cmd_str = ""
|
|
|
|
if env:
|
|
|
|
cmd_str += " ".join([f"{item[0]}={item[1]}" for item in env.items()])
|
|
|
|
cmd_str += " "
|
|
|
|
cmd_str += " ".join([str(x) for x in cmd])
|
|
|
|
print(cmd_str)
|
|
|
|
|
|
|
|
env_full = None
|
|
|
|
if env:
|
|
|
|
env_full = os.environ.copy()
|
|
|
|
for key, value in env.items():
|
|
|
|
env_full[key] = value
|
2019-08-30 14:20:29 +02:00
|
|
|
|
|
|
|
# Flush to ensure correct order output on Windows.
|
|
|
|
sys.stdout.flush()
|
|
|
|
sys.stderr.flush()
|
|
|
|
|
2021-09-20 13:17:01 +02:00
|
|
|
if silent:
|
Make update: Show Git LFS download progress
Solves the issue of the script potentially sitting for a long time
without having any progress reported. Confusingly, such behavior
depends on Git version.
In older versions (< 2.33) there will be progress reported, but it
then got changed by the commit in Git:
https://github.com/git/git/commit/7a132c628e57b9bceeb88832ea051395c0637b16
The delayed checkout is exactly how Git LFS integrates into the Git
process. Another affecting factor for the behavior is that submodule
configured to use "checkout" update policy is forced to have quite
flag passed to the "git checkout":
https://github.com/git/git/blob/v2.43.2/builtin/submodule--helper.c#L2258
This is done to avoid the long message at the end of checkout about
the detached state of HEAD, with instructions how to resolve that.
There are two possible solutions: either use "rebase" update policy
for submodules, or skip Git LFS download during the submodule update.
Changing the update policy is possible, but it needs to be done with
a bit of care, and possible revised process for updating/merging
tests data.
This change follows the second idea of delaying LFS download for a
later step, so the process is the following:
- Run `git submodule update`, but tell Git LFS to not resolve the links
by using GIT_LFS_SKIP_SMUDGE=1 environment variable.
- Run `git lfs pull` for the submodule, to resolve the links.
Doing so bypasses hardcoded silencing in the Git. It also potentially
allows to recover from an aborted download process.
The `git lfs pull` seems to be a nominal step to resolve the LFS links
after the smudging has been skipped. It is also how in earlier Git
versions some Windows limitations were bypassed:
https://www.mankier.com/7/git-lfs-faq
The submodule update now also receives the "--progress" flag, which
logs the initial Git repository checkout process, which further
improves the feedback.
The byproduct of this change is that an error during precompiled
libraries and tests data update is not considered to be fatal.
It seems to be more fitting with other update steps, and allows
more easily reuse some code.
There is also a cosmetic change: the messages at the end of the
update process now have their own header, allowing more easily
see them in the wall-of-text.
Pull Request: https://projects.blender.org/blender/blender/pulls/118673
2024-02-23 17:40:59 +01:00
|
|
|
retcode = subprocess.call(
|
|
|
|
cmd, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL, env=env_full)
|
2021-09-20 13:17:01 +02:00
|
|
|
else:
|
Make update: Show Git LFS download progress
Solves the issue of the script potentially sitting for a long time
without having any progress reported. Confusingly, such behavior
depends on Git version.
In older versions (< 2.33) there will be progress reported, but it
then got changed by the commit in Git:
https://github.com/git/git/commit/7a132c628e57b9bceeb88832ea051395c0637b16
The delayed checkout is exactly how Git LFS integrates into the Git
process. Another affecting factor for the behavior is that submodule
configured to use "checkout" update policy is forced to have quite
flag passed to the "git checkout":
https://github.com/git/git/blob/v2.43.2/builtin/submodule--helper.c#L2258
This is done to avoid the long message at the end of checkout about
the detached state of HEAD, with instructions how to resolve that.
There are two possible solutions: either use "rebase" update policy
for submodules, or skip Git LFS download during the submodule update.
Changing the update policy is possible, but it needs to be done with
a bit of care, and possible revised process for updating/merging
tests data.
This change follows the second idea of delaying LFS download for a
later step, so the process is the following:
- Run `git submodule update`, but tell Git LFS to not resolve the links
by using GIT_LFS_SKIP_SMUDGE=1 environment variable.
- Run `git lfs pull` for the submodule, to resolve the links.
Doing so bypasses hardcoded silencing in the Git. It also potentially
allows to recover from an aborted download process.
The `git lfs pull` seems to be a nominal step to resolve the LFS links
after the smudging has been skipped. It is also how in earlier Git
versions some Windows limitations were bypassed:
https://www.mankier.com/7/git-lfs-faq
The submodule update now also receives the "--progress" flag, which
logs the initial Git repository checkout process, which further
improves the feedback.
The byproduct of this change is that an error during precompiled
libraries and tests data update is not considered to be fatal.
It seems to be more fitting with other update steps, and allows
more easily reuse some code.
There is also a cosmetic change: the messages at the end of the
update process now have their own header, allowing more easily
see them in the wall-of-text.
Pull Request: https://projects.blender.org/blender/blender/pulls/118673
2024-02-23 17:40:59 +01:00
|
|
|
retcode = subprocess.call(cmd, env=env_full)
|
2021-09-20 13:17:01 +02:00
|
|
|
|
2019-09-08 14:17:58 +02:00
|
|
|
if exit_on_error and retcode != 0:
|
|
|
|
sys.exit(retcode)
|
|
|
|
return retcode
|
|
|
|
|
2020-10-02 02:10:01 +02:00
|
|
|
|
2022-09-16 02:49:49 +02:00
|
|
|
def check_output(cmd: Sequence[str], exit_on_error: bool = True) -> str:
|
2019-09-08 14:17:58 +02:00
|
|
|
# Flush to ensure correct order output on Windows.
|
|
|
|
sys.stdout.flush()
|
|
|
|
sys.stderr.flush()
|
|
|
|
|
|
|
|
try:
|
2019-09-08 18:44:47 +02:00
|
|
|
output = subprocess.check_output(cmd, stderr=subprocess.STDOUT, universal_newlines=True)
|
2019-09-08 14:17:58 +02:00
|
|
|
except subprocess.CalledProcessError as e:
|
|
|
|
if exit_on_error:
|
2024-02-22 13:50:55 +01:00
|
|
|
sys.stderr.write(" ".join(cmd) + "\n")
|
2019-09-08 14:17:58 +02:00
|
|
|
sys.stderr.write(e.output + "\n")
|
|
|
|
sys.exit(e.returncode)
|
|
|
|
output = ""
|
|
|
|
|
|
|
|
return output.strip()
|
2019-08-29 11:13:41 +02:00
|
|
|
|
2020-10-02 02:10:01 +02:00
|
|
|
|
2023-02-27 10:58:58 +01:00
|
|
|
def git_local_branch_exists(git_command: str, branch: str) -> bool:
|
|
|
|
return (
|
|
|
|
call([git_command, "rev-parse", "--verify", branch], exit_on_error=False, silent=True) == 0
|
|
|
|
)
|
|
|
|
|
|
|
|
|
2023-05-23 17:49:43 +02:00
|
|
|
def git_remote_branch_exists(git_command: str, remote: str, branch: str) -> bool:
|
|
|
|
return call([git_command, "rev-parse", "--verify", f"remotes/{remote}/{branch}"],
|
|
|
|
exit_on_error=False, silent=True) == 0
|
|
|
|
|
|
|
|
|
2022-09-16 02:49:49 +02:00
|
|
|
def git_branch_exists(git_command: str, branch: str) -> bool:
|
2022-04-20 07:08:46 +02:00
|
|
|
return (
|
2023-02-27 10:58:58 +01:00
|
|
|
git_local_branch_exists(git_command, branch) or
|
2023-05-23 17:49:43 +02:00
|
|
|
git_remote_branch_exists(git_command, "upstream", branch) or
|
|
|
|
git_remote_branch_exists(git_command, "origin", branch)
|
2022-04-20 07:08:46 +02:00
|
|
|
)
|
2021-09-20 13:17:01 +02:00
|
|
|
|
|
|
|
|
2023-02-28 05:12:04 +01:00
|
|
|
def git_get_remote_url(git_command: str, remote_name: str) -> str:
|
2023-02-21 16:39:58 +01:00
|
|
|
return check_output((git_command, "ls-remote", "--get-url", remote_name))
|
|
|
|
|
|
|
|
|
|
|
|
def git_remote_exist(git_command: str, remote_name: str) -> bool:
|
|
|
|
"""Check whether there is a remote with the given name"""
|
|
|
|
# `git ls-remote --get-url upstream` will print an URL if there is such remote configured, and
|
|
|
|
# otherwise will print "upstream".
|
|
|
|
remote_url = check_output((git_command, "ls-remote", "--get-url", remote_name))
|
|
|
|
return remote_url != remote_name
|
|
|
|
|
|
|
|
|
|
|
|
def git_is_remote_repository(git_command: str, repo: str) -> bool:
|
|
|
|
"""Returns true if the given repository is a valid/clonable git repo"""
|
|
|
|
exit_code = call((git_command, "ls-remote", repo, "HEAD"), exit_on_error=False, silent=True)
|
|
|
|
return exit_code == 0
|
|
|
|
|
|
|
|
|
2022-09-16 02:49:49 +02:00
|
|
|
def git_branch(git_command: str) -> str:
|
2024-02-22 13:50:55 +01:00
|
|
|
"""Get current branch name."""
|
|
|
|
|
2019-08-29 11:13:41 +02:00
|
|
|
try:
|
|
|
|
branch = subprocess.check_output([git_command, "rev-parse", "--abbrev-ref", "HEAD"])
|
|
|
|
except subprocess.CalledProcessError as e:
|
|
|
|
sys.stderr.write("Failed to get Blender git branch\n")
|
|
|
|
sys.exit(1)
|
|
|
|
|
2019-10-09 14:41:34 +02:00
|
|
|
return branch.strip().decode('utf8')
|
|
|
|
|
2020-10-02 02:10:01 +02:00
|
|
|
|
2023-02-21 16:39:58 +01:00
|
|
|
def git_get_config(git_command: str, key: str, file: Optional[str] = None) -> str:
|
|
|
|
if file:
|
|
|
|
return check_output([git_command, "config", "--file", file, "--get", key])
|
|
|
|
|
|
|
|
return check_output([git_command, "config", "--get", key])
|
|
|
|
|
|
|
|
|
|
|
|
def git_set_config(git_command: str, key: str, value: str, file: Optional[str] = None) -> str:
|
|
|
|
if file:
|
|
|
|
return check_output([git_command, "config", "--file", file, key, value])
|
|
|
|
|
|
|
|
return check_output([git_command, "config", key, value])
|
|
|
|
|
|
|
|
|
2024-02-27 20:02:15 +01:00
|
|
|
def _git_submodule_config_key(submodule_dir: Path, key: str) -> str:
|
|
|
|
submodule_dir_str = submodule_dir.as_posix()
|
|
|
|
return f"submodule.{submodule_dir_str}.{key}"
|
|
|
|
|
|
|
|
|
2024-02-28 01:02:53 +01:00
|
|
|
def is_git_submodule_enabled(git_command: str, submodule_dir: Path) -> bool:
|
2024-02-27 20:02:15 +01:00
|
|
|
"""Check whether submodule denoted by its directory within the repository is enabled"""
|
|
|
|
|
|
|
|
git_root = Path(check_output([git_command, "rev-parse", "--show-toplevel"]))
|
|
|
|
gitmodules = git_root / ".gitmodules"
|
|
|
|
|
|
|
|
# Check whether the submodule actually exists.
|
|
|
|
# Request path of an unknown submodule will cause non-zero exit code.
|
|
|
|
path = git_get_config(
|
|
|
|
git_command, _git_submodule_config_key(submodule_dir, "path"), str(gitmodules))
|
|
|
|
if not path:
|
|
|
|
return False
|
|
|
|
|
|
|
|
# When the "update" strategy is not provided explicitly in the the local configuration
|
|
|
|
# `git config` returns a non-zero exit code. For those assume the default "checkout"
|
|
|
|
# strategy.
|
|
|
|
update = check_output(
|
|
|
|
(git_command, "config", "--local", _git_submodule_config_key(submodule_dir, "update")),
|
|
|
|
exit_on_error=False)
|
|
|
|
|
|
|
|
return update.lower() != "none"
|
|
|
|
|
|
|
|
|
2024-02-28 01:02:53 +01:00
|
|
|
def git_enable_submodule(git_command: str, submodule_dir: Path) -> None:
|
2024-02-22 13:50:55 +01:00
|
|
|
"""Enable submodule denoted by its directory within the repository"""
|
2020-07-13 15:42:47 +02:00
|
|
|
|
2024-02-22 13:50:55 +01:00
|
|
|
command = (git_command,
|
|
|
|
"config",
|
|
|
|
"--local",
|
2024-02-27 20:02:15 +01:00
|
|
|
_git_submodule_config_key(submodule_dir, "update"),
|
|
|
|
"checkout")
|
|
|
|
call(command, exit_on_error=True, silent=True)
|
2020-07-13 15:42:47 +02:00
|
|
|
|
2020-10-02 02:10:01 +02:00
|
|
|
|
2024-02-27 20:02:15 +01:00
|
|
|
def git_update_submodule(git_command: str, submodule_dir: Path) -> bool:
|
2024-02-22 13:50:55 +01:00
|
|
|
"""
|
|
|
|
Update the given submodule.
|
2019-08-29 11:13:41 +02:00
|
|
|
|
2024-02-22 13:50:55 +01:00
|
|
|
The submodule is denoted by its path within the repository.
|
|
|
|
This function will initialize the submodule if it has not been initialized.
|
Make update: Show Git LFS download progress
Solves the issue of the script potentially sitting for a long time
without having any progress reported. Confusingly, such behavior
depends on Git version.
In older versions (< 2.33) there will be progress reported, but it
then got changed by the commit in Git:
https://github.com/git/git/commit/7a132c628e57b9bceeb88832ea051395c0637b16
The delayed checkout is exactly how Git LFS integrates into the Git
process. Another affecting factor for the behavior is that submodule
configured to use "checkout" update policy is forced to have quite
flag passed to the "git checkout":
https://github.com/git/git/blob/v2.43.2/builtin/submodule--helper.c#L2258
This is done to avoid the long message at the end of checkout about
the detached state of HEAD, with instructions how to resolve that.
There are two possible solutions: either use "rebase" update policy
for submodules, or skip Git LFS download during the submodule update.
Changing the update policy is possible, but it needs to be done with
a bit of care, and possible revised process for updating/merging
tests data.
This change follows the second idea of delaying LFS download for a
later step, so the process is the following:
- Run `git submodule update`, but tell Git LFS to not resolve the links
by using GIT_LFS_SKIP_SMUDGE=1 environment variable.
- Run `git lfs pull` for the submodule, to resolve the links.
Doing so bypasses hardcoded silencing in the Git. It also potentially
allows to recover from an aborted download process.
The `git lfs pull` seems to be a nominal step to resolve the LFS links
after the smudging has been skipped. It is also how in earlier Git
versions some Windows limitations were bypassed:
https://www.mankier.com/7/git-lfs-faq
The submodule update now also receives the "--progress" flag, which
logs the initial Git repository checkout process, which further
improves the feedback.
The byproduct of this change is that an error during precompiled
libraries and tests data update is not considered to be fatal.
It seems to be more fitting with other update steps, and allows
more easily reuse some code.
There is also a cosmetic change: the messages at the end of the
update process now have their own header, allowing more easily
see them in the wall-of-text.
Pull Request: https://projects.blender.org/blender/blender/pulls/118673
2024-02-23 17:40:59 +01:00
|
|
|
|
|
|
|
Returns true if the update succeeded
|
2024-02-22 13:50:55 +01:00
|
|
|
"""
|
2020-10-02 02:10:01 +02:00
|
|
|
|
Make update: Show Git LFS download progress
Solves the issue of the script potentially sitting for a long time
without having any progress reported. Confusingly, such behavior
depends on Git version.
In older versions (< 2.33) there will be progress reported, but it
then got changed by the commit in Git:
https://github.com/git/git/commit/7a132c628e57b9bceeb88832ea051395c0637b16
The delayed checkout is exactly how Git LFS integrates into the Git
process. Another affecting factor for the behavior is that submodule
configured to use "checkout" update policy is forced to have quite
flag passed to the "git checkout":
https://github.com/git/git/blob/v2.43.2/builtin/submodule--helper.c#L2258
This is done to avoid the long message at the end of checkout about
the detached state of HEAD, with instructions how to resolve that.
There are two possible solutions: either use "rebase" update policy
for submodules, or skip Git LFS download during the submodule update.
Changing the update policy is possible, but it needs to be done with
a bit of care, and possible revised process for updating/merging
tests data.
This change follows the second idea of delaying LFS download for a
later step, so the process is the following:
- Run `git submodule update`, but tell Git LFS to not resolve the links
by using GIT_LFS_SKIP_SMUDGE=1 environment variable.
- Run `git lfs pull` for the submodule, to resolve the links.
Doing so bypasses hardcoded silencing in the Git. It also potentially
allows to recover from an aborted download process.
The `git lfs pull` seems to be a nominal step to resolve the LFS links
after the smudging has been skipped. It is also how in earlier Git
versions some Windows limitations were bypassed:
https://www.mankier.com/7/git-lfs-faq
The submodule update now also receives the "--progress" flag, which
logs the initial Git repository checkout process, which further
improves the feedback.
The byproduct of this change is that an error during precompiled
libraries and tests data update is not considered to be fatal.
It seems to be more fitting with other update steps, and allows
more easily reuse some code.
There is also a cosmetic change: the messages at the end of the
update process now have their own header, allowing more easily
see them in the wall-of-text.
Pull Request: https://projects.blender.org/blender/blender/pulls/118673
2024-02-23 17:40:59 +01:00
|
|
|
# Use the two stage update process:
|
|
|
|
# - Step 1: checkout the submodule to the desired (by the parent repository) hash, but
|
|
|
|
# skip the LFS smudging.
|
|
|
|
# - Step 2: Fetch LFS files, if needed.
|
|
|
|
#
|
|
|
|
# This allows to show download progress, potentially allowing resuming the download
|
|
|
|
# progress, and even recovering from partial/corrupted checkout of submodules.
|
|
|
|
#
|
|
|
|
# This bypasses the limitation of submodules which are configured as "update=checkout"
|
|
|
|
# with regular `git submodule update` which, depending on the Git version will not report
|
|
|
|
# any progress. This is because submodule--helper.c configures Git checkout process with
|
|
|
|
# the "quiet" flag, so that there is no detached head information printed after submodule
|
|
|
|
# update, and since Git 2.33 the LFS messages "Filtering contents..." is suppressed by
|
|
|
|
#
|
|
|
|
# https://github.com/git/git/commit/7a132c628e57b9bceeb88832ea051395c0637b16
|
|
|
|
#
|
|
|
|
# Doing "git lfs pull" after checkout with GIT_LFS_SKIP_SMUDGE=true seems to be the
|
|
|
|
# valid process. For example, https://www.mankier.com/7/git-lfs-faq
|
|
|
|
|
|
|
|
env = {"GIT_LFS_SKIP_SMUDGE": "1"}
|
|
|
|
|
2024-02-28 01:02:53 +01:00
|
|
|
if call((git_command, "submodule", "update", "--init", "--progress", str(submodule_dir)),
|
Make update: Show Git LFS download progress
Solves the issue of the script potentially sitting for a long time
without having any progress reported. Confusingly, such behavior
depends on Git version.
In older versions (< 2.33) there will be progress reported, but it
then got changed by the commit in Git:
https://github.com/git/git/commit/7a132c628e57b9bceeb88832ea051395c0637b16
The delayed checkout is exactly how Git LFS integrates into the Git
process. Another affecting factor for the behavior is that submodule
configured to use "checkout" update policy is forced to have quite
flag passed to the "git checkout":
https://github.com/git/git/blob/v2.43.2/builtin/submodule--helper.c#L2258
This is done to avoid the long message at the end of checkout about
the detached state of HEAD, with instructions how to resolve that.
There are two possible solutions: either use "rebase" update policy
for submodules, or skip Git LFS download during the submodule update.
Changing the update policy is possible, but it needs to be done with
a bit of care, and possible revised process for updating/merging
tests data.
This change follows the second idea of delaying LFS download for a
later step, so the process is the following:
- Run `git submodule update`, but tell Git LFS to not resolve the links
by using GIT_LFS_SKIP_SMUDGE=1 environment variable.
- Run `git lfs pull` for the submodule, to resolve the links.
Doing so bypasses hardcoded silencing in the Git. It also potentially
allows to recover from an aborted download process.
The `git lfs pull` seems to be a nominal step to resolve the LFS links
after the smudging has been skipped. It is also how in earlier Git
versions some Windows limitations were bypassed:
https://www.mankier.com/7/git-lfs-faq
The submodule update now also receives the "--progress" flag, which
logs the initial Git repository checkout process, which further
improves the feedback.
The byproduct of this change is that an error during precompiled
libraries and tests data update is not considered to be fatal.
It seems to be more fitting with other update steps, and allows
more easily reuse some code.
There is also a cosmetic change: the messages at the end of the
update process now have their own header, allowing more easily
see them in the wall-of-text.
Pull Request: https://projects.blender.org/blender/blender/pulls/118673
2024-02-23 17:40:59 +01:00
|
|
|
exit_on_error=False, env=env) != 0:
|
|
|
|
return False
|
|
|
|
|
2024-02-28 01:02:53 +01:00
|
|
|
return call((git_command, "-C", str(submodule_dir), "lfs", "pull"),
|
Make update: Show Git LFS download progress
Solves the issue of the script potentially sitting for a long time
without having any progress reported. Confusingly, such behavior
depends on Git version.
In older versions (< 2.33) there will be progress reported, but it
then got changed by the commit in Git:
https://github.com/git/git/commit/7a132c628e57b9bceeb88832ea051395c0637b16
The delayed checkout is exactly how Git LFS integrates into the Git
process. Another affecting factor for the behavior is that submodule
configured to use "checkout" update policy is forced to have quite
flag passed to the "git checkout":
https://github.com/git/git/blob/v2.43.2/builtin/submodule--helper.c#L2258
This is done to avoid the long message at the end of checkout about
the detached state of HEAD, with instructions how to resolve that.
There are two possible solutions: either use "rebase" update policy
for submodules, or skip Git LFS download during the submodule update.
Changing the update policy is possible, but it needs to be done with
a bit of care, and possible revised process for updating/merging
tests data.
This change follows the second idea of delaying LFS download for a
later step, so the process is the following:
- Run `git submodule update`, but tell Git LFS to not resolve the links
by using GIT_LFS_SKIP_SMUDGE=1 environment variable.
- Run `git lfs pull` for the submodule, to resolve the links.
Doing so bypasses hardcoded silencing in the Git. It also potentially
allows to recover from an aborted download process.
The `git lfs pull` seems to be a nominal step to resolve the LFS links
after the smudging has been skipped. It is also how in earlier Git
versions some Windows limitations were bypassed:
https://www.mankier.com/7/git-lfs-faq
The submodule update now also receives the "--progress" flag, which
logs the initial Git repository checkout process, which further
improves the feedback.
The byproduct of this change is that an error during precompiled
libraries and tests data update is not considered to be fatal.
It seems to be more fitting with other update steps, and allows
more easily reuse some code.
There is also a cosmetic change: the messages at the end of the
update process now have their own header, allowing more easily
see them in the wall-of-text.
Pull Request: https://projects.blender.org/blender/blender/pulls/118673
2024-02-23 17:40:59 +01:00
|
|
|
exit_on_error=False) == 0
|
2019-09-30 10:19:55 +02:00
|
|
|
|
2020-10-02 02:10:01 +02:00
|
|
|
|
2022-09-16 02:49:49 +02:00
|
|
|
def command_missing(command: str) -> bool:
|
2019-09-30 10:19:55 +02:00
|
|
|
# Support running with Python 2 for macOS
|
|
|
|
if sys.version_info >= (3, 0):
|
|
|
|
return shutil.which(command) is None
|
2024-02-22 13:50:55 +01:00
|
|
|
return False
|
2022-09-15 18:08:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
class BlenderVersion:
|
2022-09-16 02:49:49 +02:00
|
|
|
def __init__(self, version: int, patch: int, cycle: str):
|
2022-09-15 18:08:15 +02:00
|
|
|
# 293 for 2.93.1
|
|
|
|
self.version = version
|
|
|
|
# 1 for 2.93.1
|
|
|
|
self.patch = patch
|
|
|
|
# 'alpha', 'beta', 'release', maybe others.
|
|
|
|
self.cycle = cycle
|
|
|
|
|
|
|
|
def is_release(self) -> bool:
|
|
|
|
return self.cycle == "release"
|
|
|
|
|
|
|
|
def __str__(self) -> str:
|
|
|
|
"""Convert to version string.
|
|
|
|
|
|
|
|
>>> str(BlenderVersion(293, 1, "alpha"))
|
|
|
|
'2.93.1-alpha'
|
|
|
|
>>> str(BlenderVersion(327, 0, "release"))
|
|
|
|
'3.27.0'
|
|
|
|
"""
|
|
|
|
version_major = self.version // 100
|
|
|
|
version_minor = self.version % 100
|
|
|
|
as_string = f"{version_major}.{version_minor}.{self.patch}"
|
|
|
|
if self.is_release():
|
|
|
|
return as_string
|
|
|
|
return f"{as_string}-{self.cycle}"
|
|
|
|
|
2022-09-16 02:49:49 +02:00
|
|
|
|
2022-09-15 18:08:15 +02:00
|
|
|
def parse_blender_version() -> BlenderVersion:
|
|
|
|
blender_srcdir = Path(__file__).absolute().parent.parent.parent
|
|
|
|
version_path = blender_srcdir / "source/blender/blenkernel/BKE_blender_version.h"
|
|
|
|
|
|
|
|
version_info = {}
|
|
|
|
line_re = re.compile(r"^#define (BLENDER_VERSION[A-Z_]*)\s+([0-9a-z]+)$")
|
|
|
|
|
|
|
|
with version_path.open(encoding="utf-8") as version_file:
|
|
|
|
for line in version_file:
|
|
|
|
match = line_re.match(line.strip())
|
|
|
|
if not match:
|
|
|
|
continue
|
|
|
|
version_info[match.group(1)] = match.group(2)
|
|
|
|
|
|
|
|
return BlenderVersion(
|
|
|
|
int(version_info["BLENDER_VERSION"]),
|
|
|
|
int(version_info["BLENDER_VERSION_PATCH"]),
|
|
|
|
version_info["BLENDER_VERSION_CYCLE"],
|
|
|
|
)
|