Feat: Fork a Repo #312
Feat: Fork a Repo #312
Conversation
|
I think we'd call it "make a copy" instead of "fork" because we're not tracking the upstream repo like what GitHub did. This "make-a-copy" feature is good enough, as we don't have a proper VCS to support the real fork now. Also, it would be nice to name the new repo "Copy of XXX" instead of leaving it untitled, where XXX could be:
|
I agree. Besides, open a new tab or navigate to the copied repo in place, which method do you prefer? |
|
Good idea, I’d prefer opening a new tab. |
| <Button | ||
| endIcon={<ContentCopyIcon />} | ||
| onClick={async () => { | ||
| const result = await copyRepo(); |
There was a problem hiding this comment.
This is interesting; I didn't know we could await for the mutation function. Looks like we indeed can.
| }); | ||
|
|
||
| // Add all nodes without parent/child relationship to the new repo. | ||
| // TODO: it updates the parent/child relationship automatically somehow,maybe because the parentId? Try to figure out why, then refactor addPods method. |
There was a problem hiding this comment.
Two comments:
- The parent/children relationship is a single relation (named the
PARENTrelation in the schema). Thus, updating one should automatically update another. We should probably only update theparentfield and not touch thechildrenfield at all. - Yep, providing the
parentIdfield seems to be equivalent of using{connect: {parent: {id}}}Prisma clause.
|
I've made some small updates to the copied repo name, the button name, and the new-tab behavior. Merging. |
Make a copy of the current repo and navigate to the copied repo (untitled) in-place.
Because the only difference is the repo id (URL), so it looks exactly the same after clicking on the button, just keep an eye on the address in your browser.