TWS/meta
9
0
Fork 1
Code Issues 17 Pull requests 2 Packages Projects 2 Releases Wiki Activity

Expanded on details #15

Open
evanb wants to merge 1 commit from evanb/meta-tasks:main into main
pull from: evanb/meta-tasks:main
merge into: TWS:main
Conversation 6 Commits 1 Files changed 1 +52 -10
evanb commented 2023-08-10 16:55:22 +00:00
Member
Copy link

Expanded upon @todtb's outline. Made the steps more detailed. This should make it so anyone can follow no matter the skill level. Don't forget that even though you may know what you are doing others may have a trouble following along.

Expanded upon @todtb's outline. Made the steps more detailed. This should make it so anyone can follow no matter the skill level. Don't forget that even though you may know what you are doing others may have a trouble following along.
evanb added 1 commit 2023-08-10 16:55:23 +00:00 
Made the steps more detailed.
scott approved these changes 2023-08-10 17:24:48 +00:00
new_projects.md
@ -13,0 +12,4 @@
Here we will clone the main repository and do some initial setup.
1. Clone the repository to your machine, where `<PROJECT>` is the name of the project.
```
git clone https://git.tams.tech/TWS/<PROJECT>
scott commented 2023-08-10 17:11:16 +00:00
Owner
Copy link

I would use the ssh URL and perhaps make a note of how it differs from github ssh URLs.

May also be worth having a separate note about SSH keys and their use in forgejo

I would use the ssh URL and perhaps make a note of how it differs from github ssh URLs. May also be worth having a separate note about SSH keys and their use in forgejo
evanb commented 2023-08-10 17:34:22 +00:00
Author
Member
Copy link

From a simplicity stand point using https is, well, simpler. No need to set up SSH keys to get started.

Now is that great practice? Probably not but yes there could be a section for setting up SSH keys and using the SSH URL. I was debating about adding it into this doc or creating a separate doc about utilizing ssh.

From a simplicity stand point using `https` is, well, simpler. No need to set up SSH keys to get started. Now is that great practice? Probably not but yes there could be a section for setting up SSH keys and using the SSH URL. I was debating about adding it into this doc or creating a separate doc about utilizing ssh.
todtb commented 2023-08-11 13:54:22 +00:00
Member
Copy link

👍

Maybe

git clone ssh://git@git.tams.tech:2222/TWS/<PROJECT>
[see setting up ssh](link)

or

git clone https://git.tams.tech/TWS/<PROJECT>
👍 Maybe ```md git clone ssh://git@git.tams.tech:2222/TWS/<PROJECT> [see setting up ssh](link) or git clone https://git.tams.tech/TWS/<PROJECT> ```
👍 1
evanb commented 2023-08-11 16:27:36 +00:00
Author
Member
Copy link

Oooh yeah I like how that looks. I will draft an ssh page and figure something out with the URL.

Oooh yeah I like how that looks. I will draft an ssh page and figure something out with the URL.
new_projects.md
@ -13,0 +32,4 @@
git commit -m init
git push origin main
```
5. Once the changes can be seen at `https://git.tams.tech/TWS/<PROJECT>`, you can delete the local repository on your computer.
scott commented 2023-08-10 17:15:13 +00:00
Owner
Copy link

Why delete the local copy?

Why delete the local copy?
evanb commented 2023-08-10 17:39:26 +00:00
Author
Member
Copy link

Because we are done working with TWS/<PROJECT>. I want to drive home that once it's initialized we are done working from it and will be using the fork instead.

Because we are done working with `TWS/<PROJECT>`. I want to drive home that once it's initialized we are done working from it and will be using the fork instead.
👍 1
new_projects.md
@ -13,0 +41,4 @@
1. Visit `https://git.tams.tech/TWS/<PROJECT>` and in the upper right hand corner press "`Fork`".
2. Leave everything default as all the information for 'Owner', 'Repository Name' & 'Description' should be correct. Press "`Fork Repository`".
3. You should now be able to visit `https://git.tams.tech/<YOU>/<PROJECT>`, where `<YOU>` is your username & `<PROJECT>` is the name of the project.
4. Clone the repository to your machine.
scott commented 2023-08-10 17:23:58 +00:00
Owner
Copy link

I would use

git remote rename origin upstream
git remote add origin ...
I would use ``` git remote rename origin upstream git remote add origin ... ```
evanb commented 2023-08-10 17:46:00 +00:00
Author
Member
Copy link

Yes one could do it this way. @todtb's original outline said click the fork button so I ran with that. I stated at the top of the section that I this write up will describe how to fork in the web interface.

There could be another section that states how to fork from the CLI, changing the remotes but to my knowledge that would still require creating a repo under your username. Can you just push to an arbitrary URL and the project will be created? I know that's how the AUR works...

Yes one could do it this way. @todtb's original outline said click the fork button so I ran with that. I stated at the top of the section that I this write up will describe how to fork in the web interface. There could be another section that states how to fork from the CLI, changing the remotes but to my knowledge that would still require creating a repo under your username. Can you just push to an arbitrary URL and the project will be created? I know that's how the AUR works...
todtb commented 2023-08-11 13:50:56 +00:00
Member
Copy link

The original outline was rather slapdash, just to get something out there, so feel free to deviate from it significantly.

The original outline was rather slapdash, just to get something out there, so feel free to deviate from it significantly.
scott commented 2023-08-24 13:15:40 +00:00
Owner
Copy link

There could be another section that states how to fork from the CLI

As far as I'm aware this is not possible. The issue I had isn't with using the web UI for the fork button, it was the idea that a fork is a separate repository rather than a new remote added to an existing repo.

> There could be another section that states how to fork from the CLI As far as I'm aware this is not possible. The issue I had isn't with using the web UI for the fork button, it was the idea that a fork is a separate repository rather than a new remote added to an existing repo.
scott commented 2023-08-10 17:25:29 +00:00
Owner
Copy link

I agree the added detail is good, thank you

I agree the added detail is good, thank you
todtb approved these changes 2023-08-11 13:54:38 +00:00
scott commented 2023-08-24 13:13:48 +00:00
Owner
Copy link

Sorry, I disagreed really strongly about the idea of deleting and re-cloning the repo after forking. Just being quiet about it isn't a good way to handle that. The reason I disagreed is because they aren't separate repositories, they are forks, with a shared history. Trying to act like they're separate things seems confusing to me, and I'm not sure I understand the rationale for it. If we don't want people to push to the main repository, and only contribute through forks, we should simply disallow pushing to the main repo.

Furthermore, as we were discussing earlier, that strategy only really works when dealing with open-source software. We do want to encourage openness in general, as a way to ensure that our work goes towards encouraging freedom, but that is ultimately the decision of the client. It's also common to keep things closed until an initial release, and then open the repository up.

So I think we need an additional set of instructions for a proprietary workflow.

I was also thinking perhaps "creating a new feature" should be a separate doc from "create a new repository".

Maybe it would be good to talk about this real-time with a real-time collaborative text editor (Hedgedoc?) to try to hammer out the details of this?

Sorry, I disagreed really strongly about the idea of deleting and re-cloning the repo after forking. Just being quiet about it isn't a good way to handle that. The reason I disagreed is because they aren't separate repositories, they are forks, with a shared history. Trying to act like they're separate things seems confusing to me, and I'm not sure I understand the rationale for it. If we don't want people to push to the main repository, and only contribute through forks, we should simply disallow pushing to the main repo. Furthermore, as we were discussing earlier, that strategy only really works when dealing with open-source software. We do want to encourage openness in general, as a way to ensure that our work goes towards encouraging freedom, but that is ultimately the decision of the client. It's also common to keep things closed until an initial release, and then open the repository up. So I think we need an additional set of instructions for a proprietary workflow. I was also thinking perhaps "creating a new feature" should be a separate doc from "create a new repository". Maybe it would be good to talk about this real-time with a real-time collaborative text editor (Hedgedoc?) to try to hammer out the details of this?
todtb commented 2023-08-24 13:58:20 +00:00
Member
Copy link

Maybe it would be good to talk about this real-time with a real-time collaborative text editor (Hedgedoc?) to try to hammer out the details of this?

Happy to discuss this synchronously.

If we don't want people to push to the main repository, and only contribute through forks, we should simply disallow pushing to the main repo.

Definitely an option

deleting and re-cloning the repo after forking

I think what @evanb was saying was only deleting the local clone. Mainly to avoid confusion. You could certainly leave it on your machine, as long as new work was done on your fork. Personally, I don't care to be to prescriptive with how contributors work on/maintain their machine or workflows. As long as it is understood that you don't push straight to the main repo (and we can enforce that as you mentioned), I have no concerns.

Also, yes, this pattern is most common in open source repos. Many organizations simply protect the main branch and enforce all commits to come through branch merges after peer review. So we can forgo the fork approach if that's what you were getting at? That's fine with me too.

> Maybe it would be good to talk about this real-time with a real-time collaborative text editor (Hedgedoc?) to try to hammer out the details of this? Happy to discuss this synchronously. > If we don't want people to push to the main repository, and only contribute through forks, we should simply disallow pushing to the main repo. Definitely an option > deleting and re-cloning the repo after forking I think what @evanb was saying was only deleting the local clone. Mainly to avoid confusion. You could certainly leave it on your machine, as long as new work was done on your fork. Personally, I don't care to be to prescriptive with how contributors work on/maintain their machine or workflows. As long as it is understood that you don't push straight to the main repo (and we can enforce that as you mentioned), I have no concerns. Also, yes, this pattern is most common in open source repos. Many organizations simply protect the main branch and enforce all commits to come through branch merges after peer review. So we can forgo the fork approach if that's what you were getting at? That's fine with me too.
scott commented 2023-08-24 15:41:27 +00:00
Owner
Copy link

Oh, one thing, I think a lot of this might be simplified by creating a template repo rather than relying too much on documentation. E.G. putting placeholder README, LICENSE, .gitignore, etc.

Oh, one thing, I think a lot of this might be simplified by creating a template repo rather than relying too much on documentation. E.G. putting placeholder README, LICENSE, .gitignore, etc.
evanb commented 2023-08-24 17:15:15 +00:00
Author
Member
Copy link

Ok... a lot to unpack here,

Maybe it would be good to talk about this real-time with a real-time collaborative text editor (Hedgedoc?) to try to hammer out the details of this?

Lets, I am down for a discussion. Maybe a Matrix thread? The latter part is exactly what I am after. What are your thoughts how do you want to handle things.

So I think we need an additional set of instructions for a proprietary workflow.

The discussion of having a repo private happened after I make these changes. I have noted them and it will be updated at a later point, along with the ssh and license.

I was also thinking perhaps "creating a new feature" should be a separate doc from "create a new repository".
Correct. You could branch out to a number of dedicated files for whatever heading/opic.

I think what @evanb was saying was only deleting the local clone. Mainly to avoid confusion. You could certainly leave it on your machine, as long as new work was done on your fork. Personally, I don't care to be to prescriptive with how contributors work on/maintain their machine or workflows. As long as it is understood that you don't push straight to the main repo (and we can enforce that as you mentioned), I have no concerns.

Spot on. Don't read to much into what I have. I document so my grandma can follow along, if you know what you are doing, you do you. I personally would find it annoying if we had a doc/section for every which way of doing something. That would get really confusing.

this pattern is most common in open source repos. Many organizations simply protect the main branch and enforce all commits to come through branch merges after peer review. So we can forgo the fork approach if that's what you were getting at? That's fine with me too.
I agree with @todtb either way can work.

Ok... a lot to unpack here, > Maybe it would be good to talk about this real-time with a real-time collaborative text editor (Hedgedoc?) to try to hammer out the details of this? Lets, I am down for a discussion. Maybe a Matrix thread? The latter part is exactly what I am after. What are your thoughts how do you want to handle things. > So I think we need an additional set of instructions for a proprietary workflow. The discussion of having a repo private happened after I make these changes. I have noted them and it will be updated at a later point, along with the ssh and license. > I was also thinking perhaps "creating a new feature" should be a separate doc from "create a new repository". Correct. You could branch out to a number of dedicated files for whatever heading/opic. > I think what @evanb was saying was only deleting the local clone. Mainly to avoid confusion. You could certainly leave it on your machine, as long as new work was done on your fork. Personally, I don't care to be to prescriptive with how contributors work on/maintain their machine or workflows. As long as it is understood that you don't push straight to the main repo (and we can enforce that as you mentioned), I have no concerns. Spot on. Don't read to much into what I have. I document so my grandma can follow along, if you know what you are doing, you do you. I personally would find it annoying if we had a doc/section for every which way of doing something. That would get really confusing. > this pattern is most common in open source repos. Many organizations simply protect the main branch and enforce all commits to come through branch merges after peer review. So we can forgo the fork approach if that's what you were getting at? That's fine with me too. I agree with @todtb either way can work.
evanb commented 2023-08-24 17:29:55 +00:00
Author
Member
Copy link

I think a lot of this might be simplified by creating a template repo rather than relying too much on documentation. E.G. putting placeholder README, LICENSE, .gitignore, etc.

I was going to say the exact same thing last week on our discussion on Matrix. This seems like a good idea.

> I think a lot of this might be simplified by creating a template repo rather than relying too much on documentation. E.G. putting placeholder README, LICENSE, .gitignore, etc. I was going to say the exact same thing last week on our discussion on Matrix. This seems like a good idea.
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u main:evanb-main
git checkout evanb-main

Merge

Merge the changes and update on Forgejo.
git checkout main
git merge --no-ff evanb-main
git checkout main
git merge --ff-only evanb-main
git checkout evanb-main
git rebase main
git checkout main
git merge --no-ff evanb-main
git checkout main
git merge --squash evanb-main
git checkout main
git merge --ff-only evanb-main
git checkout main
git merge evanb-main
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
scott
todtb
Labels
Clear labels
  
backlog

something that is not urgent but may be done in the future

  
bug

Something is not working

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
help wanted

Need some help

  
invalid

Something is wrong

  
question

More information is needed

  
wontfix

This won't be fixed

No labels
backlog
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TWS/meta#15
No description provided.
Delete branch "evanb/meta-tasks:main"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?