Open AdrianVovk opened 1 year ago
For now, the work around is to use a script like this from a git pre-commit hook:
#!/usr/bin/env python3
import sys
import pathlib
from ruamel.yaml import YAML
path = pathlib.Path("project.refs")
yaml = YAML()
refs = yaml.load(path)
refs["projects"]["carbonOS"] = dict(sorted(refs["projects"]["carbonOS"].items()))
yaml.dump(refs, path)
However, this isn't ideal because:
1) pre-commit hooks aren't necessarily going to be installed
2) pre-commit hooks mutate commits in potentially unpredictable ways, which can easily mess with things like rebases, git add -p
, etc.
Wouldn't this actually lead to worse diffs compared to insertion order which should be the case right now?
If you delete your project.refs file on every re-track (like carbonOS does), no absolutely not. It ensures that project.refs
is in a stable order, which makes diffing possible in the first place. Otherwise each re-track will be in an order that's determined by which elements finished downloading first, which is essentially random and un-diffable
If you don't delete project.refs on every re-track (i.e. you preserve insertion order), I wouldn't say it leads to worse diffs. Instead of each package's ref being inserted/removed from the end of the list, it might be inserted/removed/updated somewhere in the middle
(and you probably should delete project.refs and re-create whenever you bst source track **.bst
, because otherwise deleting an element will never end up deleting the project.refs entry for that element and you project.refs will be nonsensically large)
proejct.refs is essentially equivalent to the .lock files produced by most languages' package managers. As far as I can tell, these usually sort things in alphabetical order for the same reason
And just compare the diffs before/after I added sorting to carbonOS:
a/project.refs
)I see. This deletion of refs sounds like very uncommon way to track, I have never seen any BuildStream projects do it. That said, using a separate refs file (rather than refs in elements) also seems quite rare in BuildStream projects. Maybe this deletion pattern does in fact make more sense with a separate refs file. When you have refs in elements, then the garbage collection aspect does not exist. Thanks for the explanation.
project.refs is currently unsorted. This makes checking the file into git quite cumbersome. It would be nice if buildstream could sort the keys by element name before writing the
project.refs
file, so that we could get cleaner git diffs out of an invocation ofbst source track **.bst