Puppy Linux Discussion Forum

In response to @RyPuppy's request, I am writing this sort of tutorial here on usage of Git and Github. Though the w3schools' tutorial on the same topic is great, still there are some topics which may not directly apply to puppylinux. So this post will be dedicated to clarify those things, and will try to act as a starter to using git and github.

Overview-

What is git?
According to wikipedia-

Git is free and open source software for distributed version control: tracking changes in any set of files, usually used for coordinating work among programmers collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows (thousands of parallel branches running on different systems).

What is github?
According to wikipedia-

GitHub, Inc. is an Internet hosting service for software development and version control using Git. It provides the distributed version control of Git plus access control, bug tracking, software feature requests, task management, continuous integration, and wikis for every project.

What is git and github used for?
git and github can be used for the following purposes-

• Manage projects

• Upload your projects on internet, so that other members of your team can also work side-by-side on the project (can be done privately as well, i.e. no one else other than your team members will be able to see the code)

• Make different branches and work on different issues side-by-side

How to install git?
git is usually part of devx.sfs of the puppylinux version you use.

devx.sfs is a sfs package, which can be loaded by just a click, contains most of the programs necessary for development, such as git, gcc, etc.. Each puppylinux version has its own devx.sfs. The devx.sfs of most of the puppylinux versions can be found here. For example- devx.sfs for fossapup64 9.5 is listed as devx_fossapup64_9.5.sfs in the site. devx.sfs can also be found here.

So, git does not need to be installed, rather the devx.sfs for your specific puppylinux version needs to be installed/loaded.

Do I need to install github as well?
Github is basically a site (github.com) which allows us to put our project/code on it. So not only there is no need for installing github, you cannot do so either.

What is a repository?
A repository refers to just a single directory ('directory' means a 'folder'), containing basically all the code, configurations and documentation files of a program, in which git is initialized, i.e. git is tracking changes in the directory. A repository could be of 2 types-

• Local Repository- A repository which 'may or may not have uploaded to internet' (doesn't matter if its present on github or so or not), but is available on a user's computer.

• Remote Repository- It is most oftenly a repository which has been uploaded on the internet. It 'may or may not be present on a user's computer', but the repository which is found on the internet is called the remote-repository.

So, for example, see my ehdd (shameless self 'non-profitable' marketing ). It has been uploaded to github, so it is a 'remote-repository'. But, I also have 'copied' (in more formal terms- 'cloned') it to my own computer. So the repository which is on my own computer is a 'local-repo' (repositories are many a times called 'repos' in short). Both are directories, still the one found on my own computer is called 'local-repo', while the one which is not found on my own computer is called 'remote-repo'.

Getting Started-

Configuring git locally-
To get started with git, you will need to set few configurations and tell git about your name and email. To do this, enter in a terminal these commands (I am using foo as user-name and foo@foobar.com as email account (fake))-
[]Configure user name-

git config --global user.name "foo"

[*]Configure user email (no authentication required)-

git config --global user.email "foo@foobar.com"

(Note that you set these credentials as your own 'actual' credentials as these credentials should preferably be same as that which you'll use while signing up with Github.)

Adding a github account-
To use git with Github, you'll need an account. For this, go to github.com and press the Sign up button on the top-right of the page. Follow the prompts you get to create your account. Note that it is preferable that you choose the same user-name and email as you typed into git earlier.

Additional git setups-
While git comes set-up to be used already, but for puppys few configurations might not work. You could always use-

git config ...

to modify a configuration, or-

git --global config ...

to perform a system-wide configuration.

Here 'system-wide' doesn't mean for modifications for 'every users'. Instead, here it refers to modifications for 'all repositories' of the user. If --global is not used, then only the current-repository's configuration will be changed (if there is any current repository, otherwise git will return error). Note that remote-repositories never contain git configurations.

For example, while using git on fossapup64-9.5, I get errors saying pager not found. I know what is pager (for examples- more or less commands), I know that it is a configuration error, so I would run-

git config --global core.pager "/bin/more"

to configure git to use /bin/more as the pager.

Note that even though all git configs can be found here, still you are 'not required' to know all of them. I also learnt about core.pager after searching a bit on internet.

git repository related commands-
w3schools's tutorial on these subjects is pretty good. I recommend that you follow the tutorial from here after (except for a single thing. Keep reading on).

The thing that w3schools doesn't point out-
w3schools' tutorial, though pretty good, still has a flaw. It doesn't point out that authentication now might not be achieved just by the use of a user password (Github has changed its policies, read this if you're interested reading the official statement), but instead tokens are introduced. Read the following guide to create and use your own tokens-
Creating tokens-

• Go to github.com. Make sure you are logged into your account.

• Click on your profile icon on the top-right. Now click on Settings.
  

• Scroll down the page and click on Developer settings (found on the bottom-left of the page)-
  

• Click on Personal access tokens in the window that opened. This will make few options appear. Now click on Tokens (classic)-
  
  (Note that it is not advised to generate tokens which never expire. DO NOT FOLLOW ME!!!)

• From here, you can generate a new token. Do remember to copy the token down to somewhere you trust, as this token next time will not be visible (I mean the real 'token' will not be visible, just an entry that 'it is a token' will be visible on the same site).

Read this page for more info.

Using created tokens for git authentication-
When you push to a remote-repo, you'd be prompted for your username and your password. Enter your github username in the username prompt, and your generated github token as your password. If the generated token did not have 'write-access' to repositories, so this process might fail.

I am tired writing credentials again and again!
Look at viewtopic.php?p=71994#p71994 or viewtopic.php?p=72014#p72014 if you feel the same !

Final Notes-

That was it from my side. If you want clarification of anything related to git/github or if you see that there could've been some more things included in this post, then please reply to the post, your views are respected (and accepted).

Also, if you want to go deep into the subject, then you may even read git documentation and Github documentation, though I myself have not read them .

Helpful posts on this thread-

Since this thread was filled with many off-topic messages, I am pointing the links for useful replies in this thread that can be helpful:

1. Using .netrc to store credentials

2. SmartGit : A GUI for GIT

3. Using bash script to add credentials

4. GIT vs. doing things manually (a.k.a. Linux terminal commands that are alternative to various GIT commands)

5. An example of the reason why GIT is required

6. What if I want to use GIT, but do not want to use GITHUB? Are there any other GITHUB-like platforms of interest?

7. The reason why GITHUB is the biggest and the most used platform for GIT

8. Odin project - A good open source online resource for learning GIT (and other sorts of coding)

9. All programming languages start with the "Hello World" example; where is it for GITHUB? (the answer is here)

And, that's all! If any of the above links are of your interest, click'em right away!

Regards
Lakshay

Something worth adding: you can use .netrc to avoid typing your credentials (or pasting your token) often.

To do that:

echo "machine github.com login YOUR_USERNAME password TOKEN" > ~/.netrc
chmod 600 ~/.netrc

Then, you can push and pull without typing your credentials.

user1234, dimkr,
Yes, I also created a classical token that never expires!

I'm using SmartGit, a GUI for git, and have created two projects on github, and that's when I discovered that github no longer accepts a password.

I only had to enter the token once, and have been using for a couple of days since then, it hasn't asked to login again.

So SmartGit is remembering it? Don't know anything about how these tokens work.

I configured SmartGit to store all data in the same folder where I expanded it, that is, in folder smartgit/.settings. I documented how that is done in this blog post:

https://bkhome.org/news/202211/openembe ... ithub.html

I would like to add, to anyone reading this, by all means learn the basics of using git, but if you do still find it confusing, take a look at SmartGit. It is closed source and a commercial program, but free for non-commercial use, and completely unrestricted.

I don't think that SmartGit is a substitute for learning the basics of how to use git, as you still need to understand the principles to use the GUI. You need to understand terms like "untracked", "commit", etc.

An extra note about SmartGit:
It has cutdown JRE and git, so you don't need to install a Java JRE or JDK, and it probably doesn't need the 'devx' sfs either.

@dimkr, @BarryK-

If you want then I can tell you my solution to this.

Lets say that my account is foo and token is bar, and the remote-repository is https://github.com/foo/foobar.git. Then I would set the origin in this way-

git remote remove origin
git remote add origin https://foo:bar@github.com/foo/foobar.git

To keep this more secure, you may want that bash doesn't save your history about this command. Then you could do that this way-

export HISTFILE_BACKUP=$HISTFILE
unset HISTFILE

git remote remove origin
git remote add origin https://foo:bar@github.com/foo/foobar.git

export HISTFILE=$HISTFILE_BACKUP
unset HISTFILE_BACKUP

I always use this, but I didn't include this in the original post as this might be a security issue.

If you use .netrc, git clone https://github.com/foo/foobar, git pull and git push will "just work".

Regarding git GUIs and the "source control" panes most IDEs have - I don't use them and don't recommend them, especially to new git users who don't know the fundamentals (think: manual transmission vs. automatic transmission). Sometimes these UIs abstract away things in a way that makes people misunderstand git and unable to fix issues themselves: in almost every workplace, I find myself volunteering to rewrite the history of a repo to remove some problematic commit, recover from an accidental merge or loss of work, separate two features into two separate branches (decouple them so one developer can continue their work on one feature while another developer changes the other), and so on. git is often misunderstood, many developers lack basic git know-how, and many git users (intentionally) use it in a very restricted and stubborn way years after they made a mistake that can be fixed rather easily with very little training. From the educational perspective, I think these UIs are a disaster, and I always prefer git: I know exactly what every command does and it offers many features these GUIs don't. With all that said, I still understand why most people I work with prefer these GUIs and fear the CLI.

@user1234 This is good stuff.

Would it be possible for you to write-up on how to build say 'Ubuntu-Jammy64' which should mimic the latest build on GitHub-woof-CE.

Thanks in advance...

RyPuppy wrote: ↑Fri Nov 11, 2022 11:30 pm

@user1234 This is good stuff.

Thankful that you liked it .

RyPuppy wrote: ↑Fri Nov 11, 2022 11:30 pm

Would it be possible for you to write-up on how to build say 'Ubuntu-Jammy64' which should mimic the latest build on GitHub-woof-CE.

Could you please elaborate what you want me to work on? Maybe you're asking about this?

user1234 wrote: ↑Sat Nov 12, 2022 8:44 am

Could you please elaborate what you want me to work on? Maybe you're asking about this?

I have been working on building Puppy-ISO locally on FossaPup.9.5. Post How to build (say Ubuntu 22 compatible) Puppy Linux can throw some insight into some of the difficulties I am facing.

Question:
1. Have you built a Puppy locally on a Laptop/Desktop running Puppy Linux ?
2. If Yes, Could you try building "Ubuntu, Jammy64, x86-64, Kernel 5.15.x" locally on your laptop ?

My goal is to build a fully functional Puppy locally on my machine. If you get actively involved in the build process, it will greatly help both of us and others with similar goals.

RyPuppy wrote: ↑Sat Nov 12, 2022 4:57 pm

1. Have you built a Puppy locally on a Laptop/Desktop running Puppy Linux ?

I am afraid, I have never. And will probably never as well.

Ditch GIT and GITHUB; use MANUAL COMMANDS INSTEAD:
DISCLAIMER:
i) This post includes intended sarcasm. NO OFFENSE
ii) This post also does not cover every function of GIT and GITHUB - only those which are required to get started with them.
iii) Read my original post on this topic to learn more about each function of git.

Topic: Why need GIT? - Part 1 of 2

Why need GIT, when we can do all its stuff manually?
Yes, we can! You don't believe me? Here is the proof:

GIT COMMAND: git clone [SOME URL]

(NOTE: [SOME URL] is the URL to a compressed file.)

MANUAL COMMANDS:

• wget [SOME URL]

• tar -xvzf [THE FILE THAT GOT DOWNLOADED]

NOTE: All the commands hereafter will be run inside the new directory that got created. Also, [DIR_NAME] will be used to denote this directory.

GIT COMMAND: git init

MANUAL COMMAND: Haha! I don't need that!

GIT COMMAND: git checkout [BRANCH NAME]
(NOTE: This command changes to the branch with specified [BRANCH NAME], creating it in case not found.)

Assuming that branch didn't exist.
MANUAL COMMANDS:

• cd ..

• cp -r [DIR_NAME] [DIR_NAME]_[BRANCH NAME]

• cd [DIR_NAME]_[BRANCH NAME]

Assuming that branch did exist.
MANUAL COMMANDS:

• cd ..

• cd [DIR_NAME]_[BRANCH NAME]

GIT COMMAND: git branch
(NOTE: This command lists all available branches.)

MANUAL COMMANDS:

• cd ..

• ls [DIR_NAME]*

GIT COMMANDS:

• Edit/create/delete some files/folders.

• git add -A

• git commit -m "[SOME MESSAGE THAT DESCRIBES THE COMMIT]"

(NOTE: This command creates a new commit.)

MANUAL COMMANDS:

• Edit/create/delete some files/folders.

• Take backup of changes.

(NOTE: While GIT stores only changes in a commit (possibly using diff), for simplicity, I have not included direct steps for taking such sort of backup. Simply, you can think of taking backup as doing cp -r ./ ../[SOME DIR NAME]).

GIT COMMANDS:
First run:

• git remote add origin [URL NAME OF REMOTE REPO]

• git push --set-upstream origin master

Subsequent runs:
git push
(NOTE: This command pushes latest commits to remote repo. Basically, this updates remote repo to become same as local repo.)

MANUAL COMMANDS:

• cd ..

• tar -cvzf [DIR_NAME]_[BRANCH_NAME].tar.gz [DIR_NAME]_[BRANCH_NAME]/

• Upload this gzipped file to some cloud service such as Mediafire.

(NOTE: Again, for simplicity, the whole directory is gzipped and uploaded every time using manual commands; while GIT just zips the changes and uploads them. This archive will also include files/folder mentioned in any .gitignore file, whereas using git, the files/folders listed in .gitignore in any sub-directory of the original source directory will not be included in neither a commit, nor while pushing.)
(NOTE 2: This type of manual setup can be seen in @mikewalsh's portables!)

GIT COMMAND: git pull
(NOTE: This command pulls latest commits to remote repo. Basically, this updates local repo to become same as remote repo.)

MANUAL COMMANDS:

• Download the latest gzipped file from the cloud service.

• tar -xvzf [DOWNLOADED FILE]

• cd [EXTRACTED FOLDER]

(NOTE: Again, this kind of manual setup can be seen with @mikewalsh's portables.)

And then, there are silly things such as git status and git diff, which do nothing exceptional - just allow us to view our latest changes (but, who even needs to view the changes that we have made by ourselves? We like to work with chaos!).

And that's all! See then, who requires that awfully difficult to use program, that uses some sort of sorcery to do the same thing we can do painstakingly?

We don't need GIT!

(Reminder: Everything except facts was a sarcasm; NO OFFENSE !)

We don't need GIT!

Yes you do. Take it from me....it is practically impossible to do version control when working manually.

I live this scenario everyday:
I build/create a raw distro and begin to polish it. After some quick tests to see if it boots and stays running I'll share it. Meanwhile still polishing the distro someone else interested takes the original version and starts adding and fixing somethings........now we are looking at 2 diverging versions of this project distro. I look over the progress and realize the stuff being added in by the other user is a really good addition.........so I begin to merge those into the original version I am working with.....now a third person comes onboard and fixes something but that is on their version of the system and needs to be merged into mine and the second fork of the same project. Suddenly there are 3 forks all diverging when in fact they should be merging.....I can't keep up.....and good fixes and additional polish gets lost.

Like with KLV-Hyprland or KLV-Airedale, so many good ideas and solutions and fixes get spread out over various versions and some have more and some have less but not easily combined.

What happens if a "fix" turns out terrible? With Git version control we can roll back.

I have been working on a Super Fossapup....a F96-CE_5+ but it goes slowly because now I have spread out over 5 machines and terabytes of server space all these versions I keep attempting to merge into one powerhouse F96 but fork after fork I end up with F96's with cryptic names that yesterday I knew what I meant when I named it....but today I look at it and wonder who made this and why?

rockedge wrote: ↑Thu Feb 08, 2024 1:59 pm

Yes you do. Take it from me....it is practically impossible to do version control when working manually.

I live this scenario everyday:
I build/create a raw distro and begin to polish it. After some quick tests to see if it boots and stays running I'll share it. Meanwhile still polishing the distro someone else interested takes the original version and starts adding and fixing somethings........now we are looking at 2 diverging versions of this project distro. I look over the progress and realize the stuff being added in by the other user is a really good addition.........so I begin to merge those into the original version I am working with.....now a third person comes onboard and fixes something but that is on their version of the system and needs to be merged into mine and the second fork of the same project. Suddenly there are 3 forks all diverging when in fact they should be merging.....I can't keep up.....and good fixes and additional polish gets lost.

Like with KLV-Hyprland or KLV-Airedale, so many good ideas and solutions and fixes get spread out over various versions and some have more and some have less but not easily combined.

What happens if a "fix" turns out terrible? With Git version control we can roll back.

I have been working on a Super Fossapup....a F96-CE_5+ but it goes slowly because now I have spread out over 5 machines and terabytes of server space all these versions I keep attempting to merge into one powerhouse F96 but fork after fork I end up with F96's with cryptic names that yesterday I knew what I meant when I named it....but today I look at it and wonder who made this and why?

user1234 wrote: ↑Thu Feb 08, 2024 11:09 am

DISCLAIMER:
i) This post includes intended sarcasm.

And, your example clearly shows the requirement of GIT - proves my point!

I recommend all programmers here on this forum to use GIT.

rockedge wrote: ↑Thu Feb 08, 2024 1:59 pm

Like with KLV-Hyprland or KLV-Airedale, so many good ideas and solutions and fixes get spread out over various versions and some have more and some have less but not easily combined.

if not github, are there any alts of interest?
https://alternativeto.net/category/deve ... e-hosting/

Hi @williwaw

williwaw wrote: ↑Thu Feb 08, 2024 10:08 pm

... if not github, are there any alts of interest? ...

Here's what another forum distro family uses for development management.

Info only.

The main advantages of GitHub over the alternatives are 1) many use it professionally or become familiar with it during college/bootcamps/..., reducing entry barriers for potential Puppy contributors and 2) the generous free tier of GitHub Actions.

https://codeberg.org/ is nice if you want free git hosting but don't want to use GitHub.

F96 does not use code, it uses manually remastering ISOs, doesn't it?

F96-CE is originally built using woof-CE following the Focal Fossa model. Then the rootfs is modified unsquashed. Then squashed and repackaged so in principle a re-master of a woof-CE build, with most of F96 made by the woof-CE process.

F96-CE was designed to be a bridge while the next Puppy Linux was being worked on that would replace Fossapup64.

I wasn't sure if this was a good source for Puppy, but I d.m.'d @dimkr and he said, "sure, why not?". So, this Odin Project Foundations course https://www.theodinproject.com/paths/fo ... oundations is free, newb-friendly, kept current, and will get you to having git properly installed, set-up and understanding how it works. You will also have a Github account and explanation of that, you'll get a crash course on VScode and how to use Chrome browser for your programming. If you're only interested in getting into Woof-CE, you can probably skip or go through the HTML, CSS, Javascript stuff quickly. One nice thing about the Odin Course is there are well-curated links throughout so you can spend as much or little time on each part depending on what your goal is. The most relevant part is from "Installation Overview" to "Git Basics", and if there's a better newb-friendly step-by-step instruction than that, nobody has put a link to it in this thread yet.

To be clear, a total newb needs two links, Odin Course https://www.theodinproject.com/paths/fo ... oundations , do that, particularly from "Installation Overview" to "Git Basics" sections. Then go to https://github.com/puppylinux-woof-CE/w ... ibutor-101 fork the repository as instructed. Granted, being able to contribute in any meaningful way will take time, but you can get set up with the tools you need and current, solid info.

I did this course from Ubuntu. But again, I asked @dimkr about doing it from Puppy, and he said "sure, why not?". So, there ya go.

What stops you from installing git or VS Code on Puppy? (All the development I do in my spare time happens on Puppy, btw)

And GitHub itself has good tutorials, like https://docs.github.com/en/get-started/ ... ello-world.

dimkr wrote: ↑Mon Feb 12, 2024 1:15 pm

And GitHub itself has good tutorials, like https://docs.github.com/en/get-started/ ... ello-world.

Allright, now we're cooking with peanut oil!! THAT is a good link, and will help me and others. I still will point out that in order for that link to be most helpful to someone they should have git installed and understand what it is and how it works, and it could only help if they have had some instruction concerning a text editor for coding and so forth. Odin Project starts at the beginning and goes all the way through. I guess someone who's been doing this stuff for so long can't remember what that is like, or doesn't understand why it's important.

One suggestion I will add is someone concerned about privacy should consider a seperate e-mail for their coding and so forth (keeping as little identifying information attached to it as possible). Conversely, if you are pursuing this in some professional capacity then you may want all this stuff associated with your professional bio and those public professional identifiers attached to whatever accounts you use in the process.

One more reason to use git is that it is an easy backup system. I'll share with you two of my experiences (one happened just few minutes ago). Both are about mistakenly deleting folders with all of my work:

1. rm -rf woof-CE-tests: This folder contained all the woof-CE builds' ISOs I downloaded and 4 scripts that I used for running them, creating save image, mounting save images, and unmounting the save images. The fact is that, I had'nt backup-ed them anywhere, since it included large ISOs and save images (.img files). I forgot what this folder had to do, and by mistake, ran rm -rf on it. It took me 2 days to re-develop those scripts. I could've instead added .gitignore in the woof-CE-tests dir and uploaded it as a private repo to my GitHub.

2. rm -rf tldr_c_client: This happened to me few minutes ago (and inspired me to make this post). I just found this GitHub repo, and instantly wanted to make a petbuild for it, since @Clarity had asked for including tldr in Jammy64 and this version passed on all the criteria I wanted for tldr: small, and easy to build. Now, whenever I create a new petbuild, I go to my local woof-CE clone, add a new directory for the petbuild and start working on it, running git add -A after every change (and later on commit after I am satisfied that all the changes I wanted in one commit are done). But, this time, due to some reason, I wanted to make this petbuild in my ~/Downloads directory, and thought I would move it into woof-CE later on. Since this directory did not have git initiated, I could not make any backups. Now, I created the petbuild, ran the tests locally (which created the directory tldr-c-client-1.6.1/), and finally decided to remove the tests and move the petbuild directory to woof-CE. Remember the new dir created? The only difference was hyphens instead of underscores and the version information. And, before I deleted the tests, I had gone away for some time; and in this interval only, I forgot that the directory to delete was not tldr_c_client but the other one. rm -rfed it, and then instant regret ! Now, I'll have to re-develop this petbuild, which will take another 10-20 minutes including the tests.

The bottom line is @user1234 has given instruction at the beginning of the thread - viewtopic.php?p=71985#p71985 @user1234 also pointed to w3schools git tutorial https://www.w3schools.com/git/default.asp IIRC, w3schools was one I considered before doing Odin Project, and I think the only reason I did Odin was a friend's recommendation based on needing to brush up on HTML, CSS, and javascript before getting into python. Which was my goal. So, for people who's goal is to engage with the Woof-CE github, w3schools might be the best one. I do remember it being highly regarded in all the info I read.

I have suggested the 7 modules in Odin Project's course (starting with Installation Overview to Git Basics) https://www.theodinproject.com/paths/fo ... oundations for people who may need a more thorough, dumbed down, simple guide. Since I did it myself, I know their way is easy to follow, and kept current, but also geared towards someone operating from an Ubuntu/Debian system. Since doing it that way, I have not had any of the problems I hear other people talk about relating to their Github account.

@dimkr suggested this, direct from Github https://docs.github.com/en/get-started/ ... ello-world I don't know if he's actually followed this guide, but it looks like a good resource and may be maintained at the same standard as Odin Project. If there was someone who did it here to tell us, then we'd know. Also, @dimkr has said here that he won't interfere. (deleted)

Very good.

trawglodyte wrote: ↑Fri Feb 16, 2024 7:39 pm

@dimkr suggested this, direct from Github https://docs.github.com/en/get-started/ ... ello-world I don't know if he's actually followed this guide

If I did, it was probably ₁₅ years ago and many things have changed since then (including the guide). But it looks like a great resource to me, it shouldn't take more than two hours to open your first PR if you follow this guide.

@trawglodyte, it does not matter much whichever introduction tutorial you take, real knowledge in programming mostly comes from experience only. Books can guide you and teach you, but unless you solve a few problems yourself related to what you've learnt, till then you can't actually say that you know the stuff .

Regards
Lakshay

real knowledge in programming mostly comes from experience only

Extremely true statement. Since 1975 I've hacked at it. NO as in ZERO formal training as programmer or developer. I wanted to be one once but life got in the way and other roads had to be taken. I ended up a soldier then learned and worked at setting the light for cinematography so I taught myself how to program starting with way back when with a very basic book on the BASIC language.

Learning GIT I just started by making an account and tying stuff. Broke stuff constantly. Fixed and broke it again......slowly gaining the knowledge and skill to do the fixing part and breaking things even in a bigger way......it's awesome....like having a soccer club one might support....it is mostly torture with a few moments of glory in between the desolation.

It's probably not great when you're simultaneously short on developers and also the developers you have are the reason you're short on developers.

It's due mostly to the old age of it....the complexity of the woof-CE code...some people just don't get Puppy Linux....some think it's a toy...
I'm not worried.....got some reinforcements coming on the horizon and getting into position. Some exciting developments and cutting edge coming in a couple of months...going to to be looking at woof-CE engine room with a big tool box in hand.......going to go deep into the woof-CE system to learn it well and plan on doing some serious design work........you should hang around and get in on the action.....lots of room on the team as you've repeatedly mentioned

If you want to participate in Puppy development but those with commit permissions refuse your contributions or stand in your way, you can fork woof-CE. Then, you can start work on your fork by deleting stuff you don't want and reducing complexity. If you regret the fork later, you can try to upstream your changes.

I am not familiar with the Odin Project. I will have to read up on it. For now I am satisfied with the ability to push a commit and do some basic stuff with Github. I'll get better with practice though.

dimkr wrote: ↑Wed Nov 09, 2022 11:34 am

Something worth adding: you can use .netrc to avoid typing your credentials (or pasting your token) often.

To do that:

Code: Select all

echo "machine github.com login YOUR_USERNAME password TOKEN" > ~/.netrc
chmod 600 ~/.netrc

Then, you can push and pull without typing your credentials.

I didn't know this before. This is useful. Thanks.