But l need to download git into my system locally for my machine to understand the command, correct ?

In that case, how do I install git ?

Same as you would anything else!

git init (if you're making a new repository)
git add somefile.kra
git commit (and then write your commit message)

Probably that's the property of git that l stumbled upon ?

But how do l save art files locally in the form of git ?

uuuhh..? I got no idea how to use VS Code, I don't use VS Code. I'm more a Kate wolf myself. (And vim, but vim is weird and clunky at first and would probably just be frustrating.)

*shoots piefed a very confused look*

Unless you meant a tutorial on git, in which case, the learngitbranching.js.org one is great.

Hello Frost, l need to play with git in order to understand how it works. The picture that l have put up is random. Posting a picture creates a link on piefed, which enables crossposting, hence putting up an image.

Nice to see your reply after quite sometime.

Right now l wish to toy with vs code. I've downloaded one yesterday. I'm not familiar with this this tool yet. It can be used used independently on windows 10, but I wish to use it on WSL.

Can you suggest me some introductory course/tutorial ?

You can always version control regular-ass documents, art files, whatever, too! You might not be able to diff them very well, but you can absolutely use git as a bunch of save states.

git is entirely local-only. You don't need to upload anything to github at all.

That picture you included is kinda weird and misleading IMO.

First thing: Ignore the "central repository". There is none. git works entirely locally (this confuses the hell out of people who grew up with CVS/SVN, for some reason). You CAN push and pull to other people's computers, if you want, or your own other computer; all Github or whatever is is a "someone else's computer" in the cloud that you can push to. But you also don't need a remote repository at all. Most of ours don't have one.

Seconding https://learngitbranching.js.org/. It's quite nice.

Some stuff you should know:

• A commit is a snapshot of everything in the project (that was added to git at the time).
• A branch is basically just a movable tag pointing to the latest commit, with which you can get to previous commits by walking the chain backwards; when you make a new commit, you move the branch to point to it.
• You can make alternate timelines by going back to a previous commit (without moving your branch pointer), making a new branch pointer (and switching to it), and editing/committing/etc. That's why they're called branches.
• There's an undo history for where your branch has been, git reflog. Can save your butt if a rebase or whatever goes sideways and you get screwed up.
• All your history is in the .git folder in your project folder. Everything. If you back that up you've got the whole history of the project.

-- Frost

Thanks for this.

Make this your background. Use a gui like gitg if you're learning, but repeat the terms on what each action is doing so you can transition to the konsole

I like to explain it as "advanced undo-redo." Most people who use computers have an intuitive understanding of undo-redo. You can ctrl-z all the way back to when the document was empty, and ctrl-y all the way forward to where you were. The difference with git is that you have to manually create those checkpoints with a commit.

But what if you ctrl-z a few times, and then type something? Most people know that all the changes they just ctrl-z'ed are gone. This is git's first advanced feature: branching. Git allows you to maintain alternate 'timelines' for your file(s), which you can hop between at will. This is also what makes it a powerful collaboration tool: everyone on the team can maintain their own personal branches.

That last capability becomes extremely powerful with the next advanced feature: merging. Git has a number of very nice tools to assist in merging timelines back together, identifying conflicts when needed. This allows teams to set up one "true" branch that is the main (we used to use a different word) timeline. That way, each developer isn't undoing and redoing on the same set of files, they can make their changes in isolation, and when a change is ready, it can be merged back into the main timeline. The proposed changes can be easily seen using git's diff tool, and can be reviewed by the team, further refined, and finally merged with the main timeline. After this operation, the two histories have been joined and everyone else can pull in and start using that change.

I find that's enough to get a new user conceptually oriented. That is, they have a good idea of what they need to do, if not the exact git commands to do it. But that's the easy part, just a quick glance at the man page is all that's needed.

https://learngitbranching.js.org/

Go in a empty directory and type git init .

Then have at it.

This is my github this gives you an idea into how l converted git. But honestly, l need something simple to start with which uses git.

Depends on the goal. Exploration for exploration sake is probably not going to hold your attention long. git is a tool to track changes. Do you have something you want to change? In other words, you need a reason to use it. Pedantically, your image already has a problem. git is not centralized. It is merely convention that some given local repo is blessed as "upstream". But the whole point is that git is distributed.

Advice: Find a reason to use git. Put your /etc/ under git control, for example. Or something in your home directory (lots of people roll some kind of dotfiles repo). Or contribute to a FOSS project that uses git.

Learnt a lot today. Exploring gradually what linux is.

You can install a terminal multiplexer: sudo apt-get install byobu - and launch it: byobu, then follow the instructions on how to use multiple CLI apps at the same time. For example, install zsh, vim, ffmpeg and other console programs you wanted, and launch them in multiple byobu tabs. If you want to install a desktop application, you can do that with apt-get as well, and WSL will create a shortcut in your Windows start menu. Basically, you work on your Windows desktop and use GNU/Linux apps at the same time.

So you work on Ubuntu ? I'm getting stuck in this bash window itself.....

You typically need to enable the Windows Feature called "Hyper-V" if it isn't enabled already. There's a bunch of documentation online if you search around, offhand these two should get you going

https://ubuntu.com/server/docs/how-to/virtualisation/ubuntu-on-hyper-v/

https://www.thewindowsclub.com/how-to-install-linux-ubuntu-on-hyper-v-in-windows

https://github.com/RidwanurRahim/Hyper-V-Ubuntu-Server (way more advanced than you need but steps 1-5 could be useful if want more how-tos)

Hints:

• You don't have to use Ubuntu if you don't want to, just do a VM install with any .iso image file (though I'd say Ubuntu is fine if you just want to tinker and get to learn basics, and Ubuntu itself is well documented)
• For the networking you typically don't need to do anything too advanced, a standard default switch to create a virtual NAT is fine for the most part. You only need to tinker with bridged networking if you intend to run a VM that pulls down its own IP address and has its own incoming internet traffic separate from your host Windows system.

So how do I use this feature ?

Windows 10/11 Pro has Microsoft Hyper-V built-in for virtualization, that would be the most straightforward to use on Windows. It can run Linux guest OSes.

https://en.wikipedia.org/wiki/Hyper-V

While I don't know whether MX Linux supports WSL (just a few distributions do), I know that MX is based on Debian, and you can install Debian under WSL with wsl --install -d Debian. Their console experience is very similar.

Thanks for sharing. The only difference is that instead of Ubuntu, l'd love to go for MX Linux, as I want to get a hang of it.

WSL is the name of the tool, it installs an Ubuntu virtual machine that integrates with Windows in a way that you don't have to care about disk sizes, shared folders or remote access. It gives you an Ubuntu bash window after a few minutes of automatic downloading. Under WSL, I do run both vim and ffmpeg OK. You can install most packages you want like on a full Ubuntu installation.

Then qemu sounds like a good tool to play with

Terminals and command lines like fish and zsh run well on windows ? Vim and ffmpeg ? They work fine on windows ?