Hi Paul, I had in mind something: I would like to cherry-pick all tzdb's commits that affect manual pages into the Linux man-pages git repository, instead of just pasting here snapshots of your manual pages. For that to work, we'd need to agree on a path inside the repository (or I could manually --or with a script-- edit each commit, which would be combersome, and I'd rather avoid). What do you think of moving the pages in the tzdb repository into man/man*/ directories? I see your repository is perfectly flat, so I don't know if there are strong reasons for that, or if it's just innertia. To be explicit, this is what I'd do in tzdb.git: diff --git a/date.1 b/man/man1/date.1 similarity index 100% rename from date.1 rename to man/man1/date.1 diff --git a/newctime.3 b/man/man3/newctime.3 similarity index 100% rename from newctime.3 rename to man/man3/newctime.3 diff --git a/newstrftime.3 b/man/man3/newstrftime.3 similarity index 100% rename from newstrftime.3 rename to man/man3/newstrftime.3 diff --git a/newtzset.3 b/man/man3/newtzset.3 similarity index 100% rename from newtzset.3 rename to man/man3/newtzset.3 diff --git a/time2posix.3 b/man/man3/time2posix.3 similarity index 100% rename from time2posix.3 rename to man/man3/time2posix.3 diff --git a/tzfile.5 b/man/man5/tzfile.5 similarity index 100% rename from tzfile.5 rename to man/man5/tzfile.5 diff --git a/tzselect.8 b/man/man8/tzselect.8 similarity index 100% rename from tzselect.8 rename to man/man8/tzselect.8 diff --git a/zdump.8 b/man/man8/zdump.8 similarity index 100% rename from zdump.8 rename to man/man8/zdump.8 diff --git a/zic.8 b/man/man8/zic.8 similarity index 100% rename from zic.8 rename to man/man8/zic.8 If we do that, then my idea would be to do $ git remote add tzdb git@github.com:eggert/tz.git in my Linux man-pages local repo, and cherry-pick commits '-- man/' from time to time. Does that sound good to you? Have a lovely day! Alex -- <https://www.alejandro-colomar.es/> A client is hiring kernel driver, mm, and/or crypto developers; contact me if interested.
On 2024-05-08 09:24, Alejandro Colomar wrote:
What do you think of moving the pages in the tzdb repository into man/man*/ directories? I see your repository is perfectly flat, so I don't know if there are strong reasons for that, or if it's just innertia.
To be fair, inertia itself is a strong reason.... I wouldn't mind renaming the man pages, though I'd get rid of the "new" prefixes while we're at it. However, I worry that other downstream users would be adversely affected. Perhaps others could chime in.
On 2024-05-09 00:57:38 (+0800), Paul Eggert via tz wrote:
On 2024-05-08 09:24, Alejandro Colomar wrote:
What do you think of moving the pages in the tzdb repository into man/man*/ directories? I see your repository is perfectly flat, so I don't know if there are strong reasons for that, or if it's just innertia.
To be fair, inertia itself is a strong reason....
I wouldn't mind renaming the man pages, though I'd get rid of the "new" prefixes while we're at it. However, I worry that other downstream users would be adversely affected. Perhaps others could chime in.
I don't mind the idea, but we (FreeBSD) would have to rework some of our tooling. I suspect other non-Linux distributions are similarly affected. Thinking out loud: would it make sense to rename the files in the Git repository, but keep the tarballs flat? I suspect most downstreams consume the tarballs rather than the Git repository. Philip
On 2024-05-08 20:36, Philip Paeps wrote:
Thinking out loud: would it make sense to rename the files in the Git repository, but keep the tarballs flat? I suspect most downstreams consume the tarballs rather than the Git repository.
You may be right. My impression is that some people do it either way. There would be some pain in the long run if the two methods put files in different places. We could arrange for the tarballs to contain two hard links or copies of the renamed files, one with the old name and one with the new. All in all, though, I'm inclined to think that if we're going to rename the files, we should just do it. The backward compatibility concerns are less with documentation location than with data or code.
On 2024-05-09 11:41:40 (+0800), Paul Eggert wrote:
On 2024-05-08 20:36, Philip Paeps wrote:
Thinking out loud: would it make sense to rename the files in the Git repository, but keep the tarballs flat? I suspect most downstreams consume the tarballs rather than the Git repository.
You may be right. My impression is that some people do it either way. There would be some pain in the long run if the two methods put files in different places.
We could arrange for the tarballs to contain two hard links or copies of the renamed files, one with the old name and one with the new.
That would likely cause more confusion.
All in all, though, I'm inclined to think that if we're going to rename the files, we should just do it. The backward compatibility concerns are less with documentation location than with data or code.
I agree with this. If something is done, it should be done once. But "doing nothing" also works. So far, the only request for change has been from a consumer of documentation, not code or data.
Philip Paeps via tz <tz@iana.org> writes:
But "doing nothing" also works. So far, the only request for change has been from a consumer of documentation, not code or data.
+1 for doing nothing. The tzdb file tree is still very small, so the gains from splitting it up seem small. I doubt it's worth causing any pain for existing consumers. regards, tom lane
Philip Paeps via tz <tz@iana.org> writes:
Paul Eggert via tz <tz@iana.org> writes:
I wouldn't mind renaming the man pages, though I'd get rid of the "new" prefixes while we're at it. However, I worry that other downstream users would be adversely affected. Perhaps others could chime in. I don't mind the idea, but we (FreeBSD) would have to rework some of our tooling.
Speaking as the FreeBSD developer who would actually be affected by the change: it's not an issue. DES -- Dag-Erling Smørgrav - des@des.no
On 2024-05-08 10:57, Paul Eggert via tz wrote:
On 2024-05-08 09:24, Alejandro Colomar wrote:
What do you think of moving the pages in the tzdb repository into man/man*/ directories? I see your repository is perfectly flat, so I don't know if there are strong reasons for that, or if it's just innertia.
To be fair, inertia itself is a strong reason....
I wouldn't mind renaming the man pages, though I'd get rid of the "new" prefixes while we're at it. However, I worry that other downstream users would be adversely affected. Perhaps others could chime in.
Not seeing any obvious man[1358] references in Linux distro RPM specs/builds: presumably rely on man-pages. Gentoo reported https://bugs.gentoo.org/920035 sys-libs/timezone-data: installs man3 manpages without corresponding libraries. Some BSDs seem to customize utilities and man pages (or use old releases) based on online man pages. What about updating glibc/manual/time.texi, and are any (non-info) docs or man pages generated from that in any distro or downstream? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
[ trimmed cc to tz only ] Can we step back a moment? I am confused by the initial request: Alejandro Colomar via tz <tz@iana.org> wrote on Wed, 8 May 2024 at 12:24:40 EDT in <vexmpmalky6xddplkpr6md6b7r664gmyt3fthmmiuxnwwiw3fu@55ga4tnb5zuj>:
I had in mind something: I would like to cherry-pick all tzdb's commits that affect manual pages into the Linux man-pages git repository, instead of just pasting here snapshots of your manual pages.
For that to work, we'd need to agree on a path inside the repository (or I could manually --or with a script-- edit each commit, which would be combersome, and I'd rather avoid).
Why is this second paragraph true? Why can you not cherry-pick all commits that touch a filename ending in the *.[0-9] glob (of which there are only 9)? That does not seem terribly onerous. However, a different concern may be that many commits that touch man pages also touch code, and rightly so: when code changes, documentation should change, and doing so in the same commit is proper. (Also there are non-man docuemntation files that change, such as NEWS). So I'm not really sure git cherry-picking at the commit level is the right thing here, although perhaps that's a simple enough way to think filtering diff hunks or whatever. -- jhawk@alum.mit.edu John Hawkinson
John Hawkinson via tz wrote in <Zj0as7x9HxQcgmJ1@louder-room.local>: |[ trimmed cc to tz only ] | |Can we step back a moment? I am confused by the initial request: | |Alejandro Colomar via tz <tz@iana.org> wrote on Wed, 8 May 2024 |at 12:24:40 EDT in <vexmpmalky6xddplkpr6md6b7r664gmyt3fthmmiuxnwwiw3fu@5\ |5ga4tnb5zuj>: | |> I had in mind something: I would like to cherry-pick all tzdb's commits |> that affect manual pages into the Linux man-pages git repository, |> instead of just pasting here snapshots of your manual pages. |> |> For that to work, we'd need to agree on a path inside the repository (or |> I could manually --or with a script-- edit each commit, which would be |> combersome, and I'd rather avoid). | |Why is this second paragraph true? | |Why can you not cherry-pick all commits that touch a filename ending \ |in the *.[0-9] glob (of which there are only 9)? | |That does not seem terribly onerous. | |However, a different concern may be that many commits that touch man \ |pages also touch code, and rightly so: when code changes, documentation \ |should change, and doing so in the same commit is proper. (Also there \ |are non-man docuemntation files that change, such as NEWS). | |So I'm not really sure git cherry-picking at the commit level is the \ |right thing here, although perhaps that's a simple enough way to think \ |filtering diff hunks or whatever. I agree, he should possibly simply "git show" or "git archive" the manual files over from each commit that touched them, and then simply "git add" them in the target, which automatically gives you the diff(1) hunks. (I do this often, even automated as part of release processes (to dedicated release branches), as it avoids any possible merge conflict.) --End of <Zj0as7x9HxQcgmJ1@louder-room.local> --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)
Hi Steffen, John, On Thu, May 09, 2024 at 10:28:23PM GMT, Steffen Nurpmeso wrote:
John Hawkinson via tz wrote in <Zj0as7x9HxQcgmJ1@louder-room.local>: |[ trimmed cc to tz only ] | |Can we step back a moment? I am confused by the initial request: | |Alejandro Colomar via tz <tz@iana.org> wrote on Wed, 8 May 2024 |at 12:24:40 EDT in <vexmpmalky6xddplkpr6md6b7r664gmyt3fthmmiuxnwwiw3fu@5\ |5ga4tnb5zuj>: | |> I had in mind something: I would like to cherry-pick all tzdb's commits |> that affect manual pages into the Linux man-pages git repository, |> instead of just pasting here snapshots of your manual pages. |> |> For that to work, we'd need to agree on a path inside the repository (or |> I could manually --or with a script-- edit each commit, which would be |> combersome, and I'd rather avoid). | |Why is this second paragraph true? | |Why can you not cherry-pick all commits that touch a filename ending \ |in the *.[0-9] glob (of which there are only 9)? | |That does not seem terribly onerous. | |However, a different concern may be that many commits that touch man \ |pages also touch code, and rightly so: when code changes, documentation \ |should change, and doing so in the same commit is proper. (Also there \ |are non-man docuemntation files that change, such as NEWS). | |So I'm not really sure git cherry-picking at the commit level is the \ |right thing here, although perhaps that's a simple enough way to think \ |filtering diff hunks or whatever.
Because in the Linux man-pages repository, I have copies of (some of) TZ's manual pages, and they're located exactly in those locations. For git-cherry-pick(1) to work with two unrelated projects that share some files, the shared files must also share location.
I agree, he should possibly simply "git show" or "git archive" the manual files over from each commit that touched them, and then simply "git add" them in the target, which automatically gives you the diff(1) hunks. (I do this often, even automated as part of release processes (to dedicated release branches), as it avoids any possible merge conflict.)
But I don't just want to import the diffs or hunks with git(1). I want to actually get the original commits from TZ, and import all their metadata: timestamp, author, message, ... It would be more or less as if the Linux man-pages was a fork of TZ; at least as far as those pages are concerned. If I didn't explain well, I can show some example with git(1). Have a lovely day! Alex
--End of <Zj0as7x9HxQcgmJ1@louder-room.local>
--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)
-- <https://www.alejandro-colomar.es/> A client is hiring kernel driver, mm, and/or crypto developers; contact me if interested.
Alejandro Colomar wrote in <fphdgf464zv4spmd76h6ye6ecvfg7dwrg7gmbljosa2pp4hf7m@lloyeqqsksua>: ... |On Thu, May 09, 2024 at 10:28:23PM GMT, Steffen Nurpmeso wrote: |> John Hawkinson via tz wrote in |> <Zj0as7x9HxQcgmJ1@louder-room.local>: ... |>|Alejandro Colomar via tz <tz@iana.org> wrote on Wed, 8 May 2024 |>|at 12:24:40 EDT in <vexmpmalky6xddplkpr6md6b7r664gmyt3fthmmiuxnwwiw3fu@5\ |>|5ga4tnb5zuj>: |>|> I had in mind something: I would like to cherry-pick all tzdb's commits |>|> that affect manual pages into the Linux man-pages git repository, |>|> instead of just pasting here snapshots of your manual pages. ... |> I agree, he should possibly simply "git show" or "git archive" the |> manual files over from each commit that touched them, and then |> simply "git add" them in the target, which automatically gives you |> the diff(1) hunks. (I do this often, even automated as part of |> release processes (to dedicated release branches), as it avoids |> any possible merge conflict.) | |But I don't just want to import the diffs or hunks with git(1). I want |to actually get the original commits from TZ, and import all their |metadata: timestamp, author, message, ... | |It would be more or less as if the Linux man-pages was a fork of TZ; at |least as far as those pages are concerned. | |If I didn't explain well, I can show some example with git(1). Well it seems to me that with some scripts this can be achieved easily, ie git show COMMIT:README gives the blob, and git show --no-patch [--pretty=XY] COMMIT gives the commit object (to the given extend), which can then be parsed and used for example to fill in the environment variables GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL GIT_COMMITTER_DATE for "git commit" accordingly. There you go. |Have a lovely day! All in return. --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)
On Mai 09 2024, Steffen Nurpmeso via tz wrote:
git show --no-patch [--pretty=XY] COMMIT
gives the commit object (to the given extend), which can then be parsed and used for example to fill in the environment variables
GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL GIT_COMMITTER_DATE
for "git commit" accordingly. There you go.
git commit -c <commit> can do that for you, if you fetch the commit into the current repository. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Hi John, Steffen, Andreas, On Thu, May 09, 2024 at 11:51:38PM GMT, Andreas Schwab wrote:
On Mai 09 2024, Steffen Nurpmeso via tz wrote:
git show --no-patch [--pretty=XY] COMMIT
gives the commit object (to the given extend), which can then be parsed and used for example to fill in the environment variables
GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL GIT_COMMITTER_DATE
for "git commit" accordingly. There you go.
git commit -c <commit> can do that for you, if you fetch the commit into the current repository.
I understand I can do all of that, which is why I said I can manualy, or with some scripts, do that. However, I'd need to at least get each diff separately, modify it with a script that fixes the location of the files, and then commit (with -c). However, if the locations match, it's waaay easier: I can just cherry pick entire ranges of commits blindly: alx@debian:~/tmp/tz$ cd a/ alx@debian:~/tmp/tz/a$ ls -la total 16 drwxrwxr-x 3 alx alx 4096 May 10 00:07 . drwxrwxr-x 4 alx alx 4096 May 10 00:09 .. drwxrwxr-x 8 alx alx 4096 May 10 00:08 .git -rw-rw-r-- 1 alx alx 12 May 10 00:08 a alx@debian:~/tmp/tz/a$ git log --oneline -p -U0 e6aae47 (HEAD -> main) f diff --git a/a b/a index 9405325..0fdf397 100644 --- a/a +++ b/a @@ -5,0 +6 @@ e +f ebac0e4 e diff --git a/a b/a index d68dd40..9405325 100644 --- a/a +++ b/a @@ -4,0 +5 @@ d +e 272741f d diff --git a/a b/a index de98044..d68dd40 100644 --- a/a +++ b/a @@ -3,0 +4 @@ c +d b26242e c diff --git a/a b/a index 422c2b7..de98044 100644 --- a/a +++ b/a @@ -2,0 +3 @@ b +c 4c731b2 b diff --git a/a b/a index 7898192..422c2b7 100644 --- a/a +++ b/a @@ -1,0 +2 @@ a +b 7bc442b a diff --git a/a b/a new file mode 100644 index 0000000..7898192 --- /dev/null +++ b/a @@ -0,0 +1 @@ +a alx@debian:~/tmp/tz/a$ cd ../b/ alx@debian:~/tmp/tz/b$ ls -la total 16 drwxrwxr-x 3 alx alx 4096 May 10 00:10 . drwxrwxr-x 4 alx alx 4096 May 10 00:09 .. drwxrwxr-x 8 alx alx 4096 May 10 00:10 .git -rw-rw-r-- 1 alx alx 4 May 10 00:10 a alx@debian:~/tmp/tz/b$ git log --oneline -p -U0 ff0f291 (HEAD -> main) init b diff --git a/a b/a new file mode 100644 index 0000000..422c2b7 --- /dev/null +++ b/a @@ -0,0 +1,2 @@ +a +b alx@debian:~/tmp/tz/b$ git remote add A ../a alx@debian:~/tmp/tz/b$ git fetch A remote: Enumerating objects: 18, done. remote: Counting objects: 100% (18/18), done. remote: Compressing objects: 100% (6/6), done. remote: Total 18 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (18/18), 5.04 KiB | 1.01 MiB/s, done. From ../a * [new branch] main -> A/main alx@debian:~/tmp/tz/b$ git cherry-pick 4c731b2..A/main [main b302880] c Date: Fri May 10 00:08:14 2024 +0200 1 file changed, 1 insertion(+) [main f37efe2] d Date: Fri May 10 00:08:41 2024 +0200 1 file changed, 1 insertion(+) [main 7bb6704] e Date: Fri May 10 00:08:47 2024 +0200 1 file changed, 1 insertion(+) [main d10ea80] f Date: Fri May 10 00:08:54 2024 +0200 1 file changed, 1 insertion(+) For commits that affect both manual pages and other files, I still need to do some extra work, but significantly less than editing patches. And maybe git-cherry-pick(1) gains the ability to filter paths in the future. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/>
Hi, On Fri, May 10, 2024 at 12:25:24AM GMT, Alejandro Colomar wrote:
Hi John, Steffen, Andreas,
On Thu, May 09, 2024 at 11:51:38PM GMT, Andreas Schwab wrote:
On Mai 09 2024, Steffen Nurpmeso via tz wrote:
git show --no-patch [--pretty=XY] COMMIT
gives the commit object (to the given extend), which can then be parsed and used for example to fill in the environment variables
GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL GIT_COMMITTER_DATE
for "git commit" accordingly. There you go.
git commit -c <commit> can do that for you, if you fetch the commit into the current repository.
I understand I can do all of that, which is why I said I can manualy, or with some scripts, do that. However, I'd need to at least get each diff separately, modify it with a script that fixes the location of the files, and then commit (with -c).
However, if the locations match, it's waaay easier: I can just cherry pick entire ranges of commits blindly:
git(1) maintainer Junio suggested a way to do it, which surprisingly works even with the different paths: $ git format-patch --stdout 2024a..tz/main \ -- tzfile.5 tzselect.8 zdump.8 zic.8 \ | git am -3; So, I don't need this change any more, it seems. Have a lovely day! Alex -- <https://www.alejandro-colomar.es/> A client is hiring kernel driver, mm, and/or crypto developers; contact me if interested.
Hi Paul, On Sat, May 11, 2024 at 02:27:08PM GMT, Alejandro Colomar wrote:
git(1) maintainer Junio suggested a way to do it, which surprisingly works even with the different paths:
$ git format-patch --stdout 2024a..tz/main \ -- tzfile.5 tzselect.8 zdump.8 zic.8 \ | git am -3;
I have published a branch where this work is at the moment: <https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/log/?...> The committer information is lost, since in the rebase I become the committer, but other than that, I imported the full history of the tz.git pages. Paul, do you have in mind releasing soon? I will act differently in the man-pages repo depending on your plans. Have a lovely weekend! Alex
So, I don't need this change any more, it seems.
Have a lovely day! Alex
-- <https://www.alejandro-colomar.es/> A client is hiring kernel driver, mm, and/or crypto developers; contact me if interested.
On 2024-05-11 05:34, Alejandro Colomar wrote:
Paul, do you have in mind releasing soon? I will act differently in the man-pages repo depending on your plans.
Do you mean, release what we have now in the development repository? Or were you thinking of some sort of grand renaming first? The former would be easy, the latter would likely take more thinking and discussion.
Hi Paul, On Sat, May 11, 2024 at 09:33:50AM GMT, Paul Eggert wrote:
On 2024-05-11 05:34, Alejandro Colomar wrote:
Paul, do you have in mind releasing soon? I will act differently in the man-pages repo depending on your plans.
Do you mean, release what we have now in the development repository?
Yep, what you have in the development repo.
Or were you thinking of some sort of grand renaming first? The former would be easy, the latter would likely take more thinking and discussion.
No; actually I don't need the renaming at all any more, thanks to Junio's (git(1) maintainer) suggestion to use `git am -3`, which works even with different paths (it somehow recognizes that the files are very similar and correctly guesses what I want to do). With Junio's suggestion, I can cherry-pick your commits by adding your remote to my local repo, and then run $ git format-patch 2024a..2024b | git am -3 from the man-pages master branch, and magically get all of your updates in the correct files, and with their git history, which is neat. So, my plan if you release as of 5b6a74fba1b3 ("Update some URLs") --or around that--, it would be useful to me, because I would already import all of your git history into the man-pages repo, and do a great merge there. If you don't, I'll probably drop the temporary changes that I have in my working branches at the moment, and re-do them again after you release 2024b. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/> A client is hiring kernel driver, mm, and/or crypto developers; contact me if interested.
Hi Paul, On Sat, May 11, 2024 at 10:44:52PM GMT, Alejandro Colomar wrote:
So, my plan if you release as of 5b6a74fba1b3 ("Update some URLs") --or around that--, it would be useful to me, because I would already import all of your git history into the man-pages repo, and do a great merge there.
If you don't, I'll probably drop the temporary changes that I have in my working branches at the moment, and re-do them again after you release 2024b.
Never mind, I've prepared a branch, and I'll rebase it with --rebase-merges when you release. I don't need any action from your side any more. ;-) Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
Steffen Nurpmeso via tz <tz@iana.org> wrote on Thu, 9 May 2024 at 17:30:08 EDT in <20240509213008.4OBYpqEG@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 moderation, 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 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 definitely an exercise outside the scope of this list. -- jhawk@alum.mit.edu John Hawkinson
John Hawkinson wrote in <Zj1Ls3B5nvdfsZHi@louder-room.local>: |Steffen Nurpmeso via tz <tz@iana.org> wrote on Thu, 9 May 2024 |at 17:30:08 EDT in <20240509213008.4OBYpqEG@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@alum.mit.edu |John Hawkinson --End of <Zj1Ls3B5nvdfsZHi@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)
participants (9)
-
Alejandro Colomar -
Andreas Schwab -
brian.inglis＠systematicsw.ab.ca -
Dag-Erling Smørgrav -
John Hawkinson -
Paul Eggert -
Philip Paeps -
Steffen Nurpmeso -
Tom Lane