Allow dashes in filter names

[hugobuddel]

From slack:

https://spextra.readthedocs.io/en/latest/filters.html#etc In this page, each filter name with '-' does not work like 'I-long' or 'Br-gamma' etc.

The NAME_REGEX introduced in #10 did not allow dashes in the filter names and these were not tested.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 76.27%. Comparing base (b9c7e69) to head (8070b62).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #52   +/-   ##
=======================================
  Coverage   76.27%   76.27%           
=======================================
  Files           8        8           
  Lines         784      784           
=======================================
  Hits          598      598           
  Misses        186      186           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[hugobuddel]

I guess we should update astropy to 6.0.1 ? I cannot easily run poetry on this machine though, so I don't want to do that within this P.R.

Apparently there is no nightly job for speXtra that tells us that it fails..

[hugobuddel]

Ok, so we should probably disable the webtests in the default multi-platform run.

By the way, isn't it kinda rude to force push someone else's branch? You could also just merge main into it, no need to rebase it. In general I prefer that, because it happens quite regularly that I get directed to pages that say "We went looking everywhere, but couldn’t find those commits."

E.g. https://github.com/AstarVienna/speXtra/pull/52/files/36f24f467b766e8bd1bd1acc0f42fb218c2ebdeb..aaf0be9c84e70dd53001276dcd58f9a4a95284f2

In general, I think that branches that have been public, that is, that others could have pulled and branched from, should not be force-pushed, because then you force everyone who has done so to manually fix their own clone. I don't really care so much when you do this with your own branches (even though I personally think it is bad form).

[hugobuddel]

E.g. https://www.atlassian.com/git/tutorials/merging-vs-rebasing

The golden rule of rebasing

Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches.

[teutoburg]

By the way, isn't it kinda rude to force push someone else's branch? You could also just merge main into it, no need to rebase it. In general I prefer that, because it happens quite regularly that I get directed to pages that say "We went looking everywhere, but couldn’t find those commits."

E.g. https://github.com/AstarVienna/speXtra/pull/52/files/36f24f467b766e8bd1bd1acc0f42fb218c2ebdeb..aaf0be9c84e70dd53001276dcd58f9a4a95284f2

In general, I think that branches that have been public, that is, that others could have pulled and branched from, should not be force-pushed, because then you force everyone who has done so to manually fix their own clone. I don't really care so much when you do this with your own branches (even though I personally think it is bad form).

I like having a linear git history. I think criss-cross merges (e.g. third figure in that link) are ugly and messy. I agree that on public branches (of others), a force push is problematic and should be avoided. In this case, I simply pressed the "update with rebase" button that GitHub showed on the PR, forgetting that this would result in a force push. I'll stay away from your branches in the future unless you specifically ask me to do otherwise, and let you deal with updating them the way you prefer 😉

Sidenote about "my own branches": I sometimes push a branch that I consider very much unfinished, either to continue working on it from a different machine, or sometimes just to have a "remote backup" of it. I usually don't create a PR for those branches until I'm more or less happy with them. I don't expect anyone to check out one of my branches before they have a PR (if someone does, that's at their own risk).

[teutoburg]

Agree on the updated regex and the added tests, don't agree on the separate webtest workflow file, see my comment over there...

[hugobuddel]

I like having a linear git history. I think criss-cross merges (e.g. third figure in that link) are ugly and messy.

The anarchist in me likes the criss-cross merges. I believe it is a tools problem. A good tool should be able to show a messy history 'as-if' branches were rebased and/or squashed, because all the information to do so is there. While the opposite is not true: the "true" history is gone once a branch is rebased/squashed.

But well, admittedly all the tools suck. (Well, they are great, but could be greater.)

And these repositories are more yours than mine now, so I'll budge and rebase this again myself once we resolve #53

I agree that on public branches (of others), a force push is problematic and should be avoided. In this case, I simply pressed the "update with rebase" button that GitHub showed on the PR, forgetting that this would result in a force push. I'll stay away from your branches in the future unless you specifically ask me to do otherwise, and let you deal with updating them the way you prefer 😉

NP. actually it seems the git UX has been improved, because it actively tells you that someone might have force-pushed and what you should do, so it isn't as bad as I recall it was.

Sidenote about "my own branches": I sometimes push a branch that I consider very much unfinished, either to continue working on it from a different machine, or sometimes just to have a "remote backup" of it. I usually don't create a PR for those branches until I'm more or less happy with them. I don't expect anyone to check out one of my branches before they have a PR (if someone does, that's at their own risk).

I do regularly get those 'commits not found' from links in email notifications, so not sure why I would be getting those though. But I don't really mind those, it is usually easy enough to figure out what happens.

[hugobuddel]

Since this PR is actually independent of #53, I've rebased (well, cherry-picked) and force pushed. Since you agreed on the actual changes here, I'll merge

[teutoburg]

But well, admittedly all the tools suck. (Well, they are great, but could be greater.)

I haven't looked at https://gitbutler.com/, but recently seen a talk where it looked rather nice. But there's no way I'm switching tools now 😅

NP. actually it seems the git UX has been improved, because it actively tells you that someone might have force-pushed and what you should do, so it isn't as bad as I recall it was.

👍

I do regularly get those 'commits not found' from links in email notifications, so not sure why I would be getting those though.

Never occurred to me tbh...

[hugobuddel]

I haven't looked at https://gitbutler.com/, but recently seen a talk where it looked rather nice. But there's no way I'm switching tools now 😅

Oh that looks awesome, I'll definitely try this out. Maybe for my epds fork (called sdpə), because there I have changes in several branches.

I do regularly get those 'commits not found' from links in email notifications, so not sure why I would be getting those though.

Never occurred to me tbh...

That's because you are the only one creating those missing commits 🎃 😉