-
-
Notifications
You must be signed in to change notification settings - Fork 337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update gitoxide repository URLs #1624
Merged
Merged
+281
−282
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This updates `Byron/gitoxide` URLs to `GitoxideLabs/gitoxide` in: - Markdown documentation, except changelogs and other such files where such changes should not be made. - Documentation comments (in .rs files). - Manifest (.toml) files, for the value of the `repository` key. - The comments appearing at the top of a sample hook that contains a repository URL as an example. When making these changes, I also allowed my editor to remove trailing whitespace in any lines in files already being edited (since, in this case, there was no disadvantage to allowing this). The gitoxide repository URL changed when the repository was moved into the recently created GitHub organization `GitoxideLabs`, as detailed in GitoxideLabs#1406. Please note that, although I believe updating the URLs to their new canonical values is useful, this is not needed to fix any broken links, since `Byron/gitoxide` URLs redirect (and hopefully will always redirect) to the coresponding `GitoxideLabs/gitoxide` URLs. While this change should not break any URLs, some affected URLs were already broken. This updates them, but they are still broken. They will be fixed in a subsequent commit. This also does not update `Byron/gitoxide` URLs in test fixtures or test cases, nor in the `Makefile`. (It may make sense to change some of those too, but it is not really a documentation change.)
A few of the links discovered to have been broken while updating them are easy to fix. This fixes those. They were broken due to changes in the repository structure or contents that were not fully reflected when the links were last updated. For example, when `git-*` crates were renamed to their current `gix-*` names, URLs were updated, but some of these were GitHub URLs where the commit hash was for a commit prior to the rename.
When a repository URL is used by itself as an example and is an old `Byron/gitoxide` URL, this changes it to `GitoxideLabs/gitoxide`. This is the only situation where updating such URLs in tests carries no disadvantage, because: - In example commit messages, it is not obvious when such a change could change commit hashes that are relevant to a test. It would also sometimes invalidate gpg signatures where present, which could be confusing even if the signature is not verified, and in commit messages with `Signed-off-by` trailers, there could be further confusion. - In fixture scripts, similar effects could occur, and also their associated archives would have to be regenerated.
For the `update-curl-fixtures` rule. Two kinds of URLs are changed: - Old `Byron/gitoxide` URLs changed to `GitoxideLabs/gitoxide`. - The `Byron/foo` URL, used to obtain a 404 response, is changed to `GitoxideLabs/foo`, which likewise does not exist. Running `make update-curl-fixtures`, stashing, applying the change committed here, then running `make update-curl-fixtures` again and doing a cursory comparison to the stash indicates that this change appears not to have broken `update-curl-fixtures`.
Thanks again for this very mindful update, something I conveniently skipped over entirely. In my mind I already moved on and probably would have relied on the redirect way too long 😅. Also I am looking forward to the follow-up that deals with the previously broken links - I'd just trust your judgement with these as well. |
3 tasks
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this pull request
Oct 14, 2024
The nonexistent repo used to get data from a 404 response in the `update-curl-fixtures` rule was formerly called `foo`. This renames it to `nonexistent`, which is more self-documenting and less likely to be created by accident, even temporarily. In 1ea08bf (GitoxideLabs#1624), it was changed from `Byron/foo` to `GitoxideLabs/foo`, going along with the change of the existing repository (gitoxide's own) from `Byron/gitoxide` to `GitoxideLabs/gitoxide`. But while `Byron/foo` would continue not to exist as long as the convention of not having a `foo` repo was maintained by `@Byron`, a `foo` repository in `GitoxideLabs` might someday be created by another developer who is not aware of its status in `Makefile`. Renaming it to `nonexistent` should make this easier to avoid.
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this pull request
Oct 14, 2024
The nonexistent repo used to get data from a 401 response in the `update-curl-fixtures` rule was formerly called `foo`. (In 1ea08bf in GitoxideLabs#1624, I had erroneously said this was for a 404 response, but the `foo` URL is the 401 URL, not the 404 URL.) This commit renames it to `nonexistent`, which is more self-documenting and less likely to be created by accident, even temporarily. In 1ea08bf (GitoxideLabs#1624), it was changed from `Byron/foo` to `GitoxideLabs/foo`, going along with the change of the existing repository (gitoxide's own) from `Byron/gitoxide` to `GitoxideLabs/gitoxide`. But while `Byron/foo` would continue not to exist as long as the convention of not having a `foo` repo was maintained by `@Byron`, a `foo` repository in `GitoxideLabs` might someday be created by another developer who is not aware of its status in `Makefile`. Renaming it to `nonexistent` should make this easier to avoid.
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this pull request
Oct 14, 2024
The nonexistent repo used to get data from a 401 response in the `update-curl-fixtures` rule was formerly called `foo`. (In 1ea08bf in GitoxideLabs#1624, I had erroneously said this was for a 404 response, but the `foo` URL is the 401 URL, not the 404 URL.) This commit renames it to `nonexistent`, which is more self-documenting and less likely to be created by accident, even temporarily. In 1ea08bf (GitoxideLabs#1624), it was changed from `Byron/foo` to `GitoxideLabs/foo`, going along with the change of the existing repository (gitoxide's own) from `Byron/gitoxide` to `GitoxideLabs/gitoxide`. But while `Byron/foo` would continue not to exist as long as the convention of not having a `foo` repo was maintained by `@Byron`, a `foo` repository in `GitoxideLabs` might someday be created by another developer who is not aware of its status in `Makefile`. Renaming it to `nonexistent` should make this easier to avoid. I tested this change with the same approach as noted for 1ea08bf.
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes
Byron/gitoxide
URLs toGitoxideLabs/gitoxide
in documentation and a few other places, now that the repository has been moved into an organization as detailed in #1406. The old URLs still work, redirecting to the new ones, so that change is not needed to fix broken links, but I think it is still a good idea. This makes the change in Markdown docs except those such as changelogs where it should not be done, in documentation comments, in manifest files, and in the documentary top-comment of thepre-push
sample hook. See 64ff0a7 for details.This also makes a few other changes to URLs that do fix broken links, which had been broken before and the above change led me to discover the breakage. For example, some links had previously had their paths updated to account for a rename without their OIDs being updated. See 65f69f7 for details. There are some more broken links I found during this process where the solution is less readily apparent; for those, I plan to open a separate PR and/or an issue requesting what should be done. It seemed to me that that those further hoped-for changes are non-blocking for this PR, since they pertain to links that were already broken and are made no worse here.
I think that when
Byron/gitoxide
appears in test data, it should usually be left unchanged, or at least not changed unless something nearby is already being changed. But in some places I think it makes sense to change it. See 507579e for details, including on why I did not change it in more places. However, I did update the URLs in theMakefile
, as detailed in 1ea08bf.