[tz] manual pages in tzdb

[Steffen Nurpmeso]

John Hawkinson wrote in
 <Zj1Ls3B5nvdfsZHi at louder-room.local>:
 |Steffen Nurpmeso via tz <tz at iana.org> wrote on Thu,  9 May 2024
 |at 17:30:08 EDT in <20240509213008.4OBYpqEG at steffen%sdaoden.eu>:
 |
 |> Well it seems to me that with some scripts this can be achieved
 |> easily, ie
 |> 
 |>   git show COMMIT:README
 |...
 |
 |I think we're waiting for Alejandro's message to emerge from list modera\
 |tion, and also this isn't really the right list to talk about how best \
 |to use tools in the git ecosystem to solve this sort of problem, however:
 |
 |I think the better approach is to use git filter-repo (the recommended \
 |successor to git filter-branch) to filter the tz repo to limit it to \
 |commits that touch the manpages, and then cherry-pick from that. Ideally \

If we really step back i must admit i did not understand the term
cherry-picking from the very start, as he talks about separate
projects, i thought.  So then you have to export the commit
somehow, and import it somewhere else (git apply or git am).  Or
you have a submodule etc, i have not much experience with this
(and only ever used one for myself, ie, including setup).

Anyhow applying patches could result in merge conflicts, which is
hard to do in an automated fashion.

 |you'd want to modify the commit messages to include the original hash \
 |as an informational element (as text), which probably means it is not \
 |as simple as "git filter-repo --path-glob '*.[1-9]'" but that is definit\
 |ely an exercise outside the scope of this list.

That for sure.  I am also by no means a git expert despite using
it since i think 2011 (just like i am not a vim expert after ~24
years), i only ever swam on the surface and use things like
update-ref and such, "maintenance" and all that, no idea.
Since the tz repo is constant, 

The nice thing about my approach is the complete automatization
(without git rerere that i also never used), also despite
completely different directory layouts.  You just dump snapshots,
the diff(1) results automatically, and if he really needs
information from the original commit he could query that and
integrate it via the environment variables that git commit has for
that purpose.

So if i were to take over say two manual files from one repo to
another i would possible do something like

  git rev-list master -- FILE1 FILE2 |
  while read h; do
    git show --no-patch --stat --pretty=oneline $h
  done

This gives a commit list covering the two files, and i could for
each commit then do "git show $h:FILEx" to get the blob, and use
show on the commit object to gain the commit data.
Very fast the above is even, i never used filter-repo.

 |--
 |jhawk at alum.mit.edu
 |John Hawkinson
 --End of <Zj1Ls3B5nvdfsZHi at louder-room.local>

Ciao and good night from Germany!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)