v.utils: update githash to be able to get the githash of every passed project
#21178
Conversation
ttytm
force-pushed
the
util/update-githash
branch
from
bd29cda
to
911492e
Compare
ttytm
force-pushed
the
util/update-githash
branch
from
911492e
to
e532524
Compare
|
Excellent work. |
| assert test_rev == version.githash(git_proj_path)! | ||
| os.write_file('README.md', '')! | ||
| os.execute_opt('git add .')! | ||
| os.execute_opt('git commit -m "test2"')! | ||
| test_rev2 := os.execute_opt('git rev-parse HEAD')!.output[..7] | ||
| test_rev2 := os.execute_opt('git rev-parse --short HEAD')!.output.trim_space() |
There was a problem hiding this comment.
That is a bit brittle, since if you do not specify the length explicitly with --short=7 for example, it will depend on https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreabbrev which says:
core.abbrev
Set the length object names are abbreviated to. If unspecified or set to "auto",
an appropriate value is computed based on the approximate number of packed objects in
your repository, which hopefully is enough for abbreviated object names to stay unique
for some time. If set to "no", no abbreviation is made and the object names are shown
in their full length. The minimum length is 4.
i.e. in the future, when the v repo grows, it may decide to use 8 characters.
There was a problem hiding this comment.
Good point, we should add that specification to that
Reworks
githashto extend its use cases by allowing it to return the githash of any passed path. Currently, it is used for@VCURRENTHASHand only returns the path of the V hash. Chances thatgithashwas called directly outside the V codebase itself are low, but it is a public function, so this change can be considered breaking.The changes:
The new functionality will enable an easy implementation of
@VMODHASHin #21091.