Change Details

Hi Team, I've just stumbled across a peculiarity that I didn't expect. On seeing that the last archived version didn't include the latest releases, I have "saved code now" via my mobile, using a GitHub `.git` URL. This led to a duplication of the entry. First up, sorry for not checking the origin URL of the existing record first. Here's the results of a current search for "hexatomic": {F3733975} As you can see, there are two issues, which aren't easy to separate in hindsight unfortunately. 1. I guess the second (`.git`-suffixed) URL is treated as having a different "target" than the one without the suffix, although they point to the same target. 2. Capitalization is preserved in the URL. It was first introduced by auto-completion on my phone, but I had reckoned it would be fixed on the SWH end, at least for the sensible parts (protocol, TLD). As for 1., I'm not sure if there is an actual semantic difference in Git between a `.git`-suffixed URL and one without suffix. Perhaps this is platform-dependent and changing it would threaten genericity in the back-end. As an end user - however - I'd have expected for these two to be treated as the same, i.e., the `.git` snapshot overwriting (or adding to) the existing snapshot without the suffix. As for 2., I know that GitHub URLs are case-sensitive with regards to at least the repoaitory path, perhaps even the user/org path, and also that there's an awful lot of forwarding involved, e.g., when a repository name has changed. Perhaps it would be worthwhile though to look into unifying the interchangeable parts of the URL, which I think would be protocol, and top-level domain.

Hi Team, I've just stumbled across a peculiarity that I didn't expect. On seeing that the last archived version didn't include the latest releases, I have "saved code now" via my mobile, using a GitHub `.git` URL. This led to a duplication of the entry. First up, sorry for not checking the origin URL of the existing record first. Here's the results of a current search for "hexatomic": {F3733975} As you can see, there are two issues, which aren't easy to separate in hindsight unfortunately. 1. I guess the second (`.git`-suffixed) URL is treated as having a different "target" than the one without the suffix, although they point to the same target. 2. Capitalization is preserved in the URL. It was first introduced by auto-completion on my phone, but I had reckoned it would be fixed on the SWH end, at least for the sensible parts (protocol, TLD). As for 1., I'm not sure if there is an actual semantic difference in Git between a `.git`-suffixed URL and one without suffix. Perhaps this is platform-dependent and changing it would threaten genericity in the back-end. As an end user - however - I'd have expected for these two to be treated as the same, i.e., the `.git` snapshot overwriting (or adding to) the existing snapshot without the suffix. As for 2., I know that GitHub URLs are case-sensitive with regards to at least the repository path, perhaps even the user/org path, and also that there's an awful lot of forwarding involved, e.g., when a repository name has changed. Perhaps it would be worthwhile though to look into unifying the interchangeable parts of the URL, which I think would be protocol, and top-level domain.

Hi Team, I've just stumbled across a peculiarity that I didn't expect. On seeing that the last archived version didn't include the latest releases, I have "saved code now" via my mobile, using a GitHub `.git` URL. This led to a duplication of the entry. First up, sorry for not checking the origin URL of the existing record first. Here's the results of a current search for "hexatomic": {F3733975} As you can see, there are two issues, which aren't easy to separate in hindsight unfortunately. 1. I guess the second (`.git`-suffixed) URL is treated as having a different "target" than the one without the suffix, although they point to the same target. 2. Capitalization is preserved in the URL. It was first introduced by auto-completion on my phone, but I had reckoned it would be fixed on the SWH end, at least for the sensible parts (protocol, TLD). As for 1., I'm not sure if there is an actual semantic difference in Git between a `.git`-suffixed URL and one without suffix. Perhaps this is platform-dependent and changing it would threaten genericity in the back-end. As an end user - however - I'd have expected for these two to be treated as the same, i.e., the `.git` snapshot overwriting (or adding to) the existing snapshot without the suffix. As for 2., I know that GitHub URLs are case-sensitive with regards to at least the repoasitory path, perhaps even the user/org path, and also that there's an awful lot of forwarding involved, e.g., when a repository name has changed. Perhaps it would be worthwhile though to look into unifying the interchangeable parts of the URL, which I think would be protocol, and top-level domain.