Bug#845297: Migration to Salsa
On Mon, Apr 30, 2018 at 12:29 AM, Alex Muntada wrote:
> Thanks for pointing that out. I've been studying smart_change.pl
> and I couldn't find where that commit you mention is happening.
The commit is done after smart_change.pl is run, by the person who is
making the change. So if we use git commit ids in the headers that
smart_change.pl writes, they need to refer to a future commit that
hasn't happened yet, whose date is unknown and therefore whose SHA-1
hash is unknowable because it depends on the date.
> Could you elaborate a bit more on the git file+metafile details?
> I'm not following you, sorry.
Each file in a git tree is associated with a hash of some data that is
the file contents prefixed with a header containing the object type
('blob' for files), a space, the file size and a NUL character.
Storing these blob object hashes in the translation-check headers
would allow us to calculate them before commits (as smart_change.pl
does with CVS revision numbers). The machinery behind the translation
comparison stuff can then easily do a git diff between the two object
hashes. Since these git object hashes refer to individual files not
trees, they work more like CVS revision numbers than git commit hashes
do. The main question is, are they compatible with all of the VCS
operations used by the translation stuff (I think they are)?
https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
The script converting all existing translation-check headers from CVS
revision numbers to git object hashes would also be more complicated,
since the cvs-revisions file produced by the git conversion contains
filenames, CVS revision IDs and corresponding git commits. So, we have
to run `git ls-tree` for each line in cvs-revisions to get the object
hashes to put into translation-check headers.
git ls-tree -zr 7c95dc979cd7184ec4f20b0dd37e73e001a22d4f
TRANSLATING.pages | cut -zf1 | cut -z -d' ' -f3
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: