Add tootik, Bugle and a few tools

aRubes commented

2023-09-20 14:48:10 +00:00

I apologize for not renaming my branch from 'main' to something else yet (like 'data'), I didn't figure out how to do it remotely yet (or via the web UI).

This is my newest additions to the _data folder. note that Postmarks might be considered to be on the misc page rather than the tools page. not sure about this. Your suggestions pls, @lostinlight and @strypey ?

I apologize for not renaming my branch from 'main' to something else yet (like 'data'), I didn't figure out how to do it remotely yet (or via the web UI). This is my newest additions to the `_data` folder. note that Postmarks might be considered to be on the misc page rather than the tools page. not sure about this. Your suggestions pls, @lostinlight and @strypey ?

aRubes added 2 commits 2023-09-20 14:48:12 +00:00

d8613044f5 Added New Server finds

ci/woodpecker/pr/woodpecker Pipeline was successful Details

ci/woodpecker/push/woodpecker Pipeline was successful Details

e7fae770b2 Added some new tools. Please note that Postmarks may optionally belong miscellaneous.json

aRubes referenced this pull request

2023-09-20 14:48:55 +00:00

How up-to-date is the miscellaneous page? #160

Minoru commented

2023-09-20 21:29:27 +00:00

Owner

Hi 👋 There is no need to rename main. Instead, create new branches off of main for each MR you intend to send. I don't know if you're using a terminal or a plugin for an editor, so I'll show CLI commands and hope you figure out how to implement that on your end.

Open the terminal and navigate to your clone of this repo.

To keep your local clone up-to-date, you should periodically merge the changes from this repo to yours. First of all, you need to tell Git where this repo is located:

git remote add upstream https://codeberg.org/fediverse/fediparty.git

Now Git knows this repo as "upstream". You only need to run this command once.

From now on, to bring your repo's main branch up-to-date, run the following:

git switch main
git pull upstream main

And push it to your fork on Codeberg just to keep everything in sync:

git push

Great, now you have an up-to-date clone, and you're itching to update some data. Let's say you want to add some new projects and tools (like you did in this exact MR). First, you need to create a new branch for these changes:

git switch main # just to be sure we're branching off `main` and not some other branch
git switch --create add-new-projects-and-tools

"add-new-projects-and-tools" is the name of the new branch. You can list all the names you currently have with git branch.

Now you work as usual: edit files, maybe verify the build, and commit the results.

The final step is to create an MR for these changes. First of all, you need to push them to Codeberg:

git push --set-upstream origin add-new-projects-and-tools

origin is what Git calls the fork from which you created your clone; in other words, that's your fork on Codeberg. --set-upstream tells Git to remember that it pushed this branch, so if you add more commits there, you can push them with git push — no need to repeat all the arguments all the time.

Now the branch is on Codeberg, and you can use the Web UI to create your MR. Or maybe click the link that's displayed in your terminal when you first push the branch.

Once the MR is merged, you need to do a bit of housekeeping:

remove the branch from which the MR was created. Maybe Codeberg does it automatically, I don't remember; if not, there's probably a button to do it
in your local clone, run git branch --delete add-new-projects-and-tools to remove your local branch
update your main branch so future MRs start with an up-to-date state:
```
git switch main
git pull upstream main
git push
```

Now, these instructions are useless at the moment because this MR is already created from main. Don't apply them yet. Once this MR is merged, please delete your local clone and your Codeberg fork, and make new ones — I think that's the easiest way to give you a clean slate. From then on, follow the instructions above, and that should let you work on multiple MRs at a time and spare @lostinlight the trouble of resolving merge conflicts.

If you're looking for some more reading on Git, I recommend http://www-cs-students.stanford.edu/~blynn/gitmagic/ It's a short, approachable book that explains all the important points via more-or-less compelling examples. If you get stuck, please comment here, or DM me at @minoru@functional.cafe; I don't promise prompt replies, but I'd love to help!

Hi 👋 There is no need to rename `main`. Instead, create new branches *off of `main`* for each MR you intend to send. I don't know if you're using a terminal or a plugin for an editor, so I'll show CLI commands and hope you figure out how to implement that on your end. Open the terminal and navigate to your clone of this repo. To keep your local clone up-to-date, you should periodically merge the changes from this repo to yours. First of all, you need to tell Git where this repo is located: ``` git remote add upstream https://codeberg.org/fediverse/fediparty.git ``` Now Git knows this repo as "upstream". You only need to run this command once. From now on, to bring your repo's `main` branch up-to-date, run the following: ``` git switch main git pull upstream main ``` And push it to your fork on Codeberg just to keep everything in sync: ``` git push ``` Great, now you have an up-to-date clone, and you're itching to update some data. Let's say you want to add some new projects and tools (like you did in this exact MR). First, you need to create a new branch for these changes: ``` git switch main # just to be sure we're branching off `main` and not some other branch git switch --create add-new-projects-and-tools ``` "add-new-projects-and-tools" is the name of the new branch. You can list all the names you currently have with `git branch`. Now you work as usual: edit files, maybe verify the build, and commit the results. The final step is to create an MR for these changes. First of all, you need to push them to Codeberg: ``` git push --set-upstream origin add-new-projects-and-tools ``` `origin` is what Git calls the fork from which you created your clone; in other words, that's your fork on Codeberg. `--set-upstream` tells Git to remember that it pushed this branch, so if you add more commits there, you can push them with `git push` — no need to repeat all the arguments all the time. Now the branch is on Codeberg, and you can use the Web UI to create your MR. Or maybe click the link that's displayed in your terminal when you first push the branch. Once the MR is merged, you need to do a bit of housekeeping: 1. remove the branch from which the MR was created. Maybe Codeberg does it automatically, I don't remember; if not, there's probably a button to do it 2. in your local clone, run `git branch --delete add-new-projects-and-tools` to remove your local branch 3. update your `main` branch so future MRs start with an up-to-date state: ``` git switch main git pull upstream main git push ``` <hr> Now, these instructions are useless at the moment because *this* MR is already created from `main`. Don't apply them yet. Once this MR is merged, please delete your local clone and your Codeberg fork, and make new ones — I think that's the easiest way to give you a clean slate. From then on, follow the instructions above, and that should let you work on multiple MRs at a time and spare @lostinlight the trouble of resolving merge conflicts. If you're looking for some more reading on Git, I recommend http://www-cs-students.stanford.edu/~blynn/gitmagic/ It's a short, approachable book that explains all the important points via more-or-less compelling examples. If you get stuck, please comment here, or DM me at @minoru@functional.cafe; I don't promise prompt replies, but I'd love to help!

❤️ 2

Minoru changed title from ~~main~~ to Add tootik, Bugle and a few tools

2023-09-20 21:30:23 +00:00

aRubes commented

2023-09-20 22:13:02 +00:00

Poster

Hi 👋 There is no need to rename main. Instead, create new branches off of main for each MR you intend to send. I don't know if you're using a terminal or a plugin for an editor, so I'll show CLI commands and hope you figure out how to implement that on your end.

Open the terminal and navigate to your clone of this repo.

To keep your local clone up-to-date, you should periodically merge the changes from this repo to yours. First of all, you need to tell .
.
.

Now, these instructions are useless at the moment because this MR is already created from main. Don't apply them yet. Once this MR is merged, please delete your local clone and your Codeberg fork, and make new ones — I think that's the easiest way to give you a clean slate. From then on, follow the instructions above, and that should let you work on multiple MRs at a time and spare @lostinlight the trouble of resolving merge conflicts.

If you're looking for some more reading on Git, I recommend http://www-cs-students.stanford.edu/~blynn/gitmagic/ It's a short, approachable book that explains all the important points via more-or-less compelling examples. If you get stuck, please comment here, or DM me at @minoru@functional.cafe; I don't promise prompt replies, but I'd love to help!

This is great instructions @Minoru. Looking forward to do that when this gets closed

> Hi 👋 There is no need to rename `main`. Instead, create new branches *off of `main`* for each MR you intend to send. I don't know if you're using a terminal or a plugin for an editor, so I'll show CLI commands and hope you figure out how to implement that on your end. > > Open the terminal and navigate to your clone of this repo. > > To keep your local clone up-to-date, you should periodically merge the changes from this repo to yours. First of all, you need to tell . . . > Now, these instructions are useless at the moment because *this* MR is already created from `main`. Don't apply them yet. Once this MR is merged, please delete your local clone and your Codeberg fork, and make new ones — I think that's the easiest way to give you a clean slate. From then on, follow the instructions above, and that should let you work on multiple MRs at a time and spare @lostinlight the trouble of resolving merge conflicts. > > If you're looking for some more reading on Git, I recommend http://www-cs-students.stanford.edu/~blynn/gitmagic/ It's a short, approachable book that explains all the important points via more-or-less compelling examples. If you get stuck, please comment here, or DM me at @minoru@functional.cafe; I don't promise prompt replies, but I'd love to help! This is great instructions @Minoru. Looking forward to do that when this gets closed

lostinlight commented

2023-09-21 15:40:24 +00:00

Owner

@Minoru Thanks for such a detailed explanation!

@aRubes Postmarkt looks more like a new software project than a tool, indeed. It's best to move it to Misc page.

One undocumented detail for the Misc page: I usually add any new items not to the bottom of the list, but right before diaspora*. This ensures that the projects we already showcase on the site's frontpage always stay at the bottom on the Misc page. So that all the other projects that are not (yet) on the front page are given higher priority on the Misc page.

On the Tools page new items are added normally, at the bottom of the list. :)

@Minoru Thanks for such a detailed explanation! @aRubes Postmarkt looks more like a new software project than a tool, indeed. It's best to move it to Misc page. One undocumented detail for the Misc page: I usually add any new items not to the bottom of the list, but right before diaspora*. This ensures that the projects we already showcase on the site's frontpage always stay at the bottom on the Misc page. So that all the other projects that are not (yet) on the front page are given higher priority on the Misc page. On the Tools page new items are added normally, at the bottom of the list. :)

👍 1

lostinlight merged commit e7fae770b2 into main

2023-09-21 15:40:34 +00:00

lostinlight commented

2023-09-21 16:14:07 +00:00

Owner

@aRubes Oh, and forgot to mention a couple of edits I need to make to your items. "Laravel" is a PHP framework, so it can be listed in "techStack", while "codeLanguage" is PHP. Under "license" you can write just "MIT", not "MIT license".

🎉 1

aRubes commented

2023-09-22 10:04:25 +00:00

Poster

@aRubes Oh, and forgot to mention a couple of edits I need to make to your items. "Laravel" is a PHP framework, so it can be listed in "techStack", while "codeLanguage" is PHP. Under "license" you can write just "MIT", not "MIT license".

Thanks @lostinlight ! Yes, I corrected that in my PR for the delightful FA list but forgot to get back here and fix this. Thank you for noticing.

I have a request: can you put those comments as data for the next time ? I just read about Json to zee whether yhere is any commenting system. My understanding is that no, but that you can create an item or substructure that will be only for comments and will be ignored by all pages reading from the file. Is this possible ? Is it risky ? It will sure help me remember the prdering rules and common pitfalls next time. There is a guide, I know, but I didn't have time to be thorough. To sum it up: if it's possible- great. If you think it inadvisable for whatever reason - feel free to reject without explaining. I'll just include my own comments file and add it to .gitignore and hopefully next time I will remember to look at it

> @aRubes Oh, and forgot to mention a couple of edits I need to make to your items. "Laravel" is a PHP framework, so it can be listed in "techStack", while "codeLanguage" is PHP. Under "license" you can write just "MIT", not "MIT license". Thanks @lostinlight ! Yes, I corrected that in my PR for the delightful FA list but forgot to get back here and fix this. Thank you for noticing. I have a request: can you put those comments as data for the next time ? I just read about Json to zee whether yhere is any commenting system. My understanding is that no, but that you can create an item or substructure that will be only for comments and will be ignored by all pages reading from the file. Is this possible ? Is it risky ? It will sure help me remember the prdering rules and common pitfalls next time. There is a guide, I know, but I didn't have time to be thorough. To sum it up: if it's possible- great. If you think it inadvisable for whatever reason - feel free to reject without explaining. I'll just include my own comments file and add it to .gitignore and hopefully next time I will remember to look at it

lostinlight commented

2023-09-29 21:05:49 +00:00

Owner

@aRubes So, you're right, we can't add comments to json, Hexo won't like it. I'm not sure if it's worth it to add comments to json explaining how to manage it. If it needs such comments, then it's badly organised and needs re-arrangements :) Perhaps we can make a Wiki page in our repo, with details about each JSON key-value pair and what kind of data is expected in there.

Add tootik, Bugle and a few tools #171