@EliahKagan cool :)

I like the look of that date

@EliahKagan I already had an account, though I haven't been using it at all. I did the tutorial :D

Since it related to what we've been doing, it was easy to understand

I'm going to make lunch. Then I'm going to write here about my goals w/r/t/ the Git-unrelated stuff in this repository, which may or may not be relevant and useful

@Zanna Sounds relevant and useful to me!

Even just looking at in in terms of the goal of learning Git, when Git is actually used it's used as part of a workflow whose goals are not usually related to Git. One should usually be thinking of those goals in deciding how to use Git.

Did you try cloning your hello-world repository with git clone?

Another thing I'm guessing you'll want to do--perhaps you've already done it--is set up a remote for the recipes repository. I was going to suggest this, after we dealt with getting that one file in a feature branch into master where you wanted it to be, and after suggesting that you try resolving a merge conflict with git mergetool. However, there is absolute no need to do either of those things before setting the repo up with a remote.

If you don't want the repo to be public, you can make it private on GitHub when you create it or at any point before you push to it for the first time (or at any time after that, though in that case someone may already have seen its contents).

sorry for my absence

I need like 15 more hours per day

And a new brain that runs well on less water or just generally doesn't fog up so badly

@EliahKagan I did not do that, but git clone is the only Git command I have used many times, usually in order to attempt to compile stuff for AU-related experiments

Although I started writing down recipes about 17 years ago, most of these files are relatively young. Over the last ~3 years I focussed on collecting recipes from various sources as quickly as possible, so I have many recipes which I have only made once

Now I need to work more on testing the recipes so I can hopefully actually cook things that fairly reliably turn out fairly edible (since I'm pretty terrible at cooking)

so, I'm moving into a new phase

but the collecting and inventing progress is still going on all the time

so there are three types of activity

my dad gave me some work on... Thursday. I hoped I'd do it on Saturday, then I hoped I'd do it on Sunday, then I did it yesterday but there were some major corrections needed. I did the corrections today and now there are more corrections

meanwhile housework is kicking my ass in the worst way. I don't even know what is taking so long. But anyway whatever happens you usually have to eat. So in all these days I haven't been able to get time to come here, I've mentally accumulated so many things I wanted to add and change in my recipes folder haha

Sounds like you may not have too much time today or in the immediate future to do more in-depth Git stuff. That's obviously fine. Feel free to ping me if/when it turns out to be a good time. These days, I do read all the messages in this room, but sometimes I notice messages later than I would if pinged. (But not pinging is also okay, of course.)

What kind of housework? (Or is the "I don't even know what is taking so long." bit an indication that the answer is complicated?)

@Zanna The GitHub repo could start out private and then be made public later.

@Zanna If you put the recipes repo on GitHub, you could file issues against the repo (using the GitHub issue tracker) about the changes you intend to make, rather than accumulating them in your mind and hoping not to forget. OTOH there's obviously lots of other ways you could keep track, plus it does take a bit of time to file each issue (as it would to keep track through other means) and that time adds up.

@EliahKagan mostly cooking and washing up and planning what to cook and buying things to cook with I think

not necessarily in that particular order...

@EliahKagan that's a good idea!

actually it would not take me much time to make the changes. Very little time. But now I'm not changing anything because I feel vaguely nervous about doing something wrong, which is obviously the opposite of how I'm supposed to feel about using source control...

Which changes? Backporting that one file from the feature branch to master?

I meant editing files

Oh.

Yeah that's even simpler.

and adding files

Also simple.

I think because I don't know what kind of overall organisation I want to have I want to sort that out first before I do anything

I think if you have changes to make now and files to add now, then you should go ahead and add them. I would guess that this would not get in the way of organizational changes later.

As I understand it, this repository is much less structurally complex than most nontrivial software repos.

Is using Git the main reason you're reluctant to do more work in the repository? If so, that is indeed the opposite of the generally desired effect.

yes

But my other thought is... it's actually quite easy to lose data in a local repository, for example by accidentally deleting the entire directory, or (though I'm not sure I'm familiar with instances of this occurring) deleting the .git subdirectory (which would destroy everything but the current working tree).

But if you have a remote with which you keep things up to date, then that problem is either somewhat mitigated (if some but not all branches are tracked on the remote) or mostly eliminated (if all branches that have data that isn't elsewhere are tracked on the remote).

Would setting up an (at least initially) private remote repository for the recipes repository be something that would put you more at ease about possible breakages?

I should also mention that using Git doesn't prevent you from making actual backups, which I think you had mentioned that you had. Nor does it make such backups unnecessary, though if the remote repository has everything important, it might be sufficient to back that up.

@Zanna Have you cloned via SSH before? One benefit of this is that you can push to the repository. Of course, you can do that with HTTPS if you authenticate, too, and you can set up credential caching for HTTPS.

But I suggest adding your public SSH key to your GitHub account--then you can nearly always avoid having to type in a password, because if you use an ssh-agent manager like seahorse or keychain, it stores your decrypted private key in memory and you only have to enter your SSH passphrase at most once per session.

I think my concern is simply irrational. It's not a real fear about data loss. I just want to have time to think about what I'm doing as it's something new, but I don't have time to think about it, so I'm just getting edgy and not doing one thing or the other.

Waiting, in order to have more of an opportunity to think about it, seems fine to me.

If you were comfortable making changes to the working tree when it wasn't a git repository, and you're less comfortable now that it is a git repository, then you might want to stop using Git for those files, even if only temporarily. Even if the reason for your reluctance to make changes is irrational, that is still a feature of the world (in this case, of you, or of the interaction between you and the machine) that is rational to account for in deciding how to proceed at the moment.

Also, I think it's worth mentioning that I think it's uncommon for people to try out as much of Git for the first time as you have on files that they are using for some other purpose that is important to them. (Especially without having a remote set up--in hindsight, I am unsure if the topics I brought up were in the best order.) Although Git is not putting your data at risk, I could definitely see that doing all the stuff with it that you've done so far could have a distracting effect.

And you have another repository now (hello-world) that you can try things out with.

true :)

I think you did suggest that it might be better to play around with a repository of unimportant stuff

Your counterpoint that you would learn things better if you used them with something meaningful was a good one. But if at this point that approach is giving diminishing or negative returns, then a less important repo could be better.

we can use both of them

Indeed!

You can even make a third repository that has both these repositories as submodules!

(Just kidding.)

(I mean you can, but there's no good reason to do that.)

I was thinking, for example, that if you wanted to try making another merge conflict and resolving it with git mergetool, which lets you use an external tool (which can be a graphical tool) to see the diffs and edit with them, then you could do that on hello-world.

The other thing you can do, which I should perhaps have mentioned first, is that (especially) if you're just trying stuff out and not making any changes you want to keep, and you have a repository of actually important stuff that you want to try it on, then you can make a copy of the repository and try it on that copy or, better, if the repository has a remote, you can clone a copy, play with that (without pushing your changes, unless you want them), and then get rid of it.

When you have a remote repository, you can even have it cloned in two places so that you can be on different branches in both, much as two separate developers/contributors might be working on separate branches on separate machines at the same time (though, uh, way less useful than that).

@EliahKagan cool! :)

I remember when I first started using Bash, I would feel nervous that I would get lost

in the huge, dark, unknown filesystem

Well bash actually is terrifying.

hahaha

:) me too I rather use python than bash :D

Yes, in Python you have to import stuff in order to be likely to accidentally subject yourself to data loss.

back later, hopefully :/

I was showing a friend redirection and piping in the shell (bash). He wasn't 100% on the syntax and semantics but wanted to try some stuff. He meant to redirect from a file. Instead he redirected to the file. The effect was to truncate that file to zero bytes. This was an actual file we were using for stuff (I think it may have been accidentally matched by a glob or something, I don't remember). Fortunately, we didn't actually lose data...

...because the file was checked in to git. :)

@Zanna k, ttyl

@EliahKagan :D

It's good dotglob is off by default.

yes!

it's super easy to delete everything you actually care about

People sometimes advise programming novices to learn shell scripting first. Sometimes even when their actual goal is to learn some other language. This is usually accompanied by claims along the lines of, "You must run gcc from the command line first! If you compile through your IDE then your brain will leak out of your left ear a fortnight later." or "The shell is the simplest and easiest of all programming languages. Nothing will go wrong!"

I am slightly exaggerating the claims that are made. But only slightly.

I don't try to discourage anyone from learning bash (or whatever shell) first, but I don't try to convince people to do it who otherwise wouldn't. The ease of totally unexpected data loss is one reason. The incredible weirdness of shells is the other.

:)

I remember when I was trying to install Ubuntu for the first time on my basketcase laptop and trying to figure out how to boot from the grub> command line without knowing what a kernel or a device file is and someone advised me to use Arch instead since it wouldn't hold my hand

@Zanna If I needed to type stuff in on the grub> rescue prompt, I'd prefer to be using Arch. I think they have documentation for how to do that. :)

But yeah that was bad advice.

@EliahKagan oooh yeah, the Arch wiki is awesome :)

Not necessarily bad for GNU/Linux novices to use Arch or even for people to suggest it, but bad as a solution or workaround for a grub> rescue prompt in another distro.

...because obviously everybody's first distro should be the Guix System (formerly GuixSD)!

Just kidding.

I've been meaning to set that up for a while now, though. I tried it out a little bit when it was very new.

I like what I know (and the small amount I've observed) of the Guix package manager.

I've long wanted a transactional package manager where manpages work.

@Zanna Specifically, it's super easy to delete or modify files in .git if dotglob is enabled. And everything except what's currently checked out (and untracked files, and unstaged changes) is stored in .git.

Of course, this is way less drastic if you push your work to a remote.

yeah, definitely a good idea!