« first day (718 days earlier)      last day (121 days later) » 

11:27 AM
She has a nice Instagram though: instagram.com/explore/tags/artiscantik/?hl=en
 
I had the thought that a branch is more of a process than a place
 
In what sense of process?
 
a project, a series of actions that has an outcome
 
I'm on my way to the Island of Castaway Thoughts.
 
@karel Welcome!
 
11:31 AM
@karel :D
 
It's a good photo though. Someone ought to use it for a geolocation challenge. It looks like Busan although obviously it isn't.
 
When you're on a branch, and you commit, the branch is updated to that new commit. So it's a pointer to a place, and the pointer moves (in the sense of changing to point to a new place automatically).
 
I got this idea from the branch I created in the hello-world repository being called readme-edits
 
Can you elaborate?
 
Sorry :) I am trying to do that
README edits are not a file(!) or a directory but a thing that you're doing
when I finished editing the README, I deleted the branch
since it wasn't needed any more
it was like a bit of scaffolding to make it safe to build something new onto the directory structure
I am thinking what I should possibly do is, instead of having a directory TO-TEST which is a cumbersome way of organising things, I should have a branch for every recipe that needs testing (one of your suggestions). When the testing is done, the branch for that recipe can be merged into the master branch and deleted. And that's how I'll know that the recipe needs work, because there's a branch for it.
 
11:42 AM
Hi @karel! :)
5 messages moved from Raiders of the Lost Downboat
@Zanna You could do that.
Would that work better than having a TO-TEST directory?
 
I don't know, but it seems like more fun
 
:)
@Zanna Yes, this is a common way to use branches in Git (though not the only purpose of them of course). It works well because Git branches are lightweight--they don't duplicate commits, they just refer to their tips. In some other version control systems, especially the older ones, branching is a big deal, and involves making a copy of everything.
 
it's a smart design
 
Also, in many version control systems, the diffs between files between successive commits are stored. In git, each commit is instead a snapshot of a state of the repository. This takes up somewhat less space than you might think, though, because each version of each file is stored only once: what a commit really contains is the hash of each file in it, and the blob (the data of the file) is stored only once per hash.
Did you try cloning your hello-world repo, making local changes, and pushing those changes?
 
11:57 AM
no, I didn't do that
 
Do you feel like doing so?
 
 
1 hour later…
1:00 PM
@Zanna It may make it inconvenient to work on more than one testing recipe at the same time.
 
1:20 PM
@EliahKagan why would that be?
@EliahKagan yes, definitely
 
@Zanna Because they're all on separate branches.
@Zanna Do you know how? Do you just want to try it, or do you want my input?
 
I have cloned it
 
Cool. How did you clone it?
Like, which protocol did you use in the URL?
 
I would much appreciate your input, but I can surely figure it out somehow if needed
@EliahKagan I went into my playground directory and typed git clone https://github.com/ZannaStar/hello-world.git
 
I can definitely give input. :)
 
1:27 PM
so, https
was there a better way?
 
I'd say it's a matter of opinion, generally speaking.
You've cloned it the same way anybody can clone it (because it's a public repo). But not anybody can push changes to it.
When you cloned it, you were not authenticated as someone who is allowed to make changes.
That's not inherently a problem, I'm just describing the situation.
The reason it's not inherently a problem is that git will perform authentication when you attempt to push.
The remote URL is an HTTPS URL, so unless you've set up credential caching, you'll have to enter a GitHub password every time you push.
With credential caching you can make it so this is less often required.
What I prefer to do is clone through an SSH URL.
 
you mentioned that option earlier I think
 
One reason is that I'm just more used to this because it use it to clone from servers I control which don't offer HTTPS cloning, so I already have the SSH analogue of credential caching set up.
But I suggest setting that up and using it nonetheless. I think it's good to not have to do password-based authentication (that is, to use key-based authentication).
 
it's more secure that way?
 
@EliahKagan I also find that ssh-agent is highly flexible, because you can use it through a program like seahorse or (what I usually use) keychain. With keychain, you enter your passphrase in one sessions, and the key is available without further authentication in other concurrently running or subsequently started sessions.
This works well for me because I often use a machine via SSH or on a virtual console, either separately from or in addition to (or in the total absence of) its GUI. But I think many users get what they need with seahorse. I don't know if Ubuntu MATE comes with seahorse integration that works seamlessly as it does with GNOME or not.
@Zanna Possibly.
I mean, in general, key-based authentication is more secure than password-based authentication. But there are other considerations; I wouldn't want to make a pronouncement about practical security without a broader picture.
 
1:37 PM
so on GitHub if I click "use SSH" it tells me I can add a new public key
 
Also, because I use SSH so much more often for Git remotes than HTTPS, I'm reluctant to make statements about what HTTPS can't do or doesn't do well, because I might just be unaware of how people do it.
 
:)
 
@Zanna Yes, you should add your public key. If you don't have an SSH key pair, you should generate one with ssh-keygen. After you add your public key, you should verify GitHub's key fingerprint before proceeding with a connection. (I suggest ssh-ing in first with ssh to do that.)
@Zanna related (conceptually)
Of course I don't mean to imply extreme absurdities like "No one should ever say X is better than Y." But I don't feel confident in claiming that HTTPS authentication for repos is inherently inferior to SSH authentication.
 
@EliahKagan that's a really good argument :)
I have a feeling I've lost my keys
 
@Zanna I think the counterargument is that one ends up comparing a language in which one is proficient (or, in Stroustrup's case, an expert) to other languages whether one wishes to or not. So I'm actually not sure if I agree with his conclusion. But I think the considerations he's articulated for why comparisons between programming languages are often not illuminating are correct and important.
@Zanna Did you generate an SSH key pair but not know where the files for it are?
 
1:47 PM
I did it a long time ago and now I have no idea what the situation is because I have not been using ssh for anything, so I don't know what I'm doing
 
Check in ~/.ssh.
The public key would be in a file named with a .pub suffix.
The private key should not be given out. GitHub doesn't need that.
 
no there is nothing like that
only -rw-r--r-- 1 zanna zanna 222 அக். 23 2017 known_hosts
 
No .ssh directory at all in your home directory?
Oh, it just doesn't have keys.
 
yeah
 
No problem... are you sure you have generated an SSH key in the past and that this is the key you want to use with GitHub?
Had you generated it for Launchpad or something?
 
1:49 PM
yeah
Would it be better to make a new one?
 
Do you have anything on Launchpad that needs it now? You could generate a new key and use that on Launchpad and GitHub (and wherever it's needed).
@Zanna Only because you don't know where the old one is.
 
yes, I'm thinking that it would be better XD
அக். is October.... 2017. That would be when I last did a clean installation. So I would have lost the keys then. Hmm. I don't know how we are supposed to manage these things at all
 
When you say, "I don't know how we are supposed to manage these things at all," can you elaborate?
 
I mean, what should we do to avoid losing these keys, but also, I am totally clueless about it
 
Oh.
You can back up the generated key files in ~/.ssh, or the whole directory.
As for generating a new key when you don't have one, run ssh-keygen.
You should put in a good passphrase.
@EliahKagan Backups of your private key should be secure and private, though. Anyone with your private key can trivially impersonate you to any person or service who thinks the key is still good.
@EliahKagan The passphrase is used to encrypt your private key on your disk.
 
2:01 PM
done
 
And GitHub has the public key?
You should make sure the GitHub server's key fingerprint matches the fingerprint shown on that linked page (and that the page is HTTPS with no scary browser warnings).
That shows two fingerprints, but if the one you see isn't the SHA256 one, I'd be... intrigued.
One way to compare them reliably is to copy the fingerprint in your terminal and paste it into a Ctrl+F search box in the browser (and make sure it highlights the key shown there as a full match).
You should not attempt to "eyeball" it. :)
Also, make sure not to accidentally copy the fingerprint from the web page and then search the web page for the fingerprint copied from it. :)
(I've seen these things done.)
(Not specifically with that GitHub page.)
@EliahKagan To expand on that, since each testing recipe is on its own branch in the setup you described, at most one testing recipe will be in the working tree at any given time. So if you wanted to work on more than one at a time on the same machine, you'd have to have two local repositories on the same machine syncing to the same remote, with different branches checked out.
In practice I suspect you'd end up making a separate testing directory somewhere and copying files back and forth between it and the repository or something. If so, it would be better to just have that directory in the repository and not have to copy.
You might actually not want to use any feature branches as part of the general workflow for the testing recipes. Even if you don't, you might still sometimes use branches to work on changes to individual recipes and merge them back in.
I'm not sure what you'll want to do, those are just my thoughts.
 
2:27 PM
@EliahKagan I got prompted for my password to unlock the private key, but whatever I entered the popup just came back. Then I got permission denied
 
This was when you ran that ssh -T command?
Also, can you describe what you mean by "the popup"? Was this graphical?
 
@EliahKagan yes
@EliahKagan yeah it was a graphical popup
 
And you entered the passphrase you set up when you generated the key?
 
yeah, a few times
but it's possible it was wrong every time, because my keyboard really sucks these days
the o key and the a key are very temperamental
among others
 
The window that pops up does not give you an option to show you what you are typing, I take it?
 
2:34 PM
indeed
I'll try it again :)
ok, it worked on the third attempt haha
 
I shouldn't blame my keyboard because it does show blobs for each character, so you can at least see whether the keypress got registered or duplicated
I wasn't paying enough attention to those the first time
sorry
 
The dialog box has a checkbox that lets you have it keep the decrypted private key in memory for the rest of the graphical desktop session. You might want to use that. :)
 
I just thought maybe I was not supposed to enter that password as it failed 4 or 5 times
but, PEBCAK
 
Seems more like Problem Exists In Keyboard to me.
So, each time you perform a remote operation in your repository, it has to authenticate (this is the case whether you use HTTPS or SSH). But it will authenticate automatically using your SSH key, now.
 
2:40 PM
also true. I wonder if I take my laptop apart and clean it it would work better
 
@EliahKagan Sorry, what the check box actually says is:
> Automatically unlock this key whenever I'm logged in
So that's way more powerful.
That uses seahorse.
You may want to use that.
 
maybe
 
Suddenly, I actually tried it in Ubuntu MATE. :)
 
nice :)
 
^^ That's what you see, right?
(Just with a different key "comment" than ek@Ilex and possibly a different border style.)
If so, then whether or not you check the box, it will remember it for the rest of the graphical login session.
If you do check the box, it will effectively remember it in all future graphical login sessions as well.
I believe the way this works is that it stores a re-encrypted copy of the decrypted private key, encrypting that copy based on your login password or an authentication token generated from your password.
It's being taken care of by gnome-keyring-daemon, even on MATE (at least on my system).
If you use a non-graphical login on the machine, though, then it won't work and you'll have to enter your passphrase. If that's a significant use case for you then you might want to use keychain.
@EliahKagan Or maybe it stores the passphrase encrypted based on your login password. I don't know.
@Zanna So, now that that's set up, you should be able to clone your repo via SSH, and you shouldn't have to enter any password or passphrase this time.
 
3:05 PM
@EliahKagan yes
 
@EliahKagan I'm not actually sure I'm right to think it uses seahorse, btw. You can see, configure, and remove the key in seahorse though.
 
sorry I was writing some probably excessively aggressive comments on the Vegetarianism site :(
 
I don't know the situation. But... If you know they're excessively aggressive...
Or is the issue that you're concerned it may be excessive but think it's probably okay but are still worried?
(I should stop asking questions about this.)
So you're in the cloned repository?
git log shows the history you expect?
You can see all your local branches, including (and at this point, only) the one that was created automatically by the clone, by running git branch as you have been doing.
But you can also pass the -a option to git branch to see remote branches too.
git branch -a
If you run:
git remote
That shows all your remotes. (A remote may have more than one branch on it of course.)
You can display detailed information about a remote by passing the name of the remote to git remote show, for example:
git remote show origin
That also connects to the remote to get current information (unless you pass the -n option to tell it not to).
 
@EliahKagan exactly
 
You'll notice that you have remote tracking branches set up (or at least one, anyway). These are the additional branches listed in the output of git branch -a. Usually I will call these "remote branches," but it is important to understand that they are copies of branches on the remote repository. They store the the last known state of those branches on the actual remote (including all the commits of course).
Those branches actually exist in your local Git repository and, as such, they can become out of date. You can also have fewer of them than there are on the remote, if branches are created on the remote before you fetch from the remote, or more, if branches are deleted on the remote.
An example of such a branch that you probably have is origin/master.
 
3:15 PM
((Maybe I should be rethinking why I'm writing those comments at all and whether I should just downvote and move on instead))
 
You don't commit to remote branches yourself.
 
@EliahKagan oooh!
 
The main things you do with them are to fetch from them and push to them. Both these operations actually communicate with the actual remote repository.
BRB in a few minutes. In the mean time git help fetch may interest you.
I'm back.
Running git fetch is one way to fetch from a remote repository.
This updates the commits in your remote-tracking branch.
Btw, I feel like I should check if I am using the term "remote tracking branch" correctly; it might be an overcorrection.
I think I've been using it correctly but I'm just gonna say "remote branch" for stuff like origin/master (which is what I did before I tried to be all accurate and whatnot).
32
A: What is a tracking branch?

VonCThe Pro Git book mentions: Tracking branches are local branches that have a direct relationship to a remote branch Not exactly. The SO question "Having a hard time understanding git-fetch" includes: There's no such concept of local tracking branches, only remote tracking branches. So ...

 
ctrl+a is not working at all and I'm only just realising how very often I use ctrl+a
@EliahKagan I do have that
 
@Zanna You mean like in gnu screen? Or Ctrl+A in graphical programs to select all?
Is it supposed to be working? Or are you talking about selecting text from your terminal?
 
3:27 PM
@EliahKagan totally reading that as I'm not getting it yet
 
I do recommend reading that but I was mainly posting it to clarify my own confusions about what terms are best to use.
You will usually conceptually think of origin/master as the branch on GitHub (or wherever the remote lives).
 
@EliahKagan to select all in graphical programs. It's not working in firefox or in telegram
 
Is it a hardware problem with the keyboard?
@EliahKagan This is like how you might think of text you read on a website as being on the web.
Even though everything you see on that website has been downloaded to your computer (and usually even saved to disk!) and that's where you're seeing it.
If the contents of the website change, you won't see the changes unless some mechanism updates your local copy with information from the website.
 
the post you linked to even has a helpful diagram! ^_^
 
:)
Yet nonetheless it's useful and feels natural to think of what you're seeing in your browser as being "on the web."
So that's what's up with remote branches like origin/master.
 
3:31 PM
@EliahKagan ok, that's a helpful analogy
 
Cool!
I had thought up that analogy because a friend of mine (a different one from the one with >) was having trouble understanding what git fetch did, but I have not actually used the analogy before now.
You might also want to save a website to your computer.
 
@EliahKagan the a key is working, though pretty badly, and the ctrl key is working in other combinations. I think I will reboot.
 
@EliahKagan Even though... it already probably is, in your browser's cache!
@Zanna Okay.
@EliahKagan But the browser cache is supposed to have whatever is known about what content the web server is providing. Conceptually it is as though you don't have a copy even though you do.
 
fixed by reboot :)
 
Excellent.
@EliahKagan This analogy is not exact here because it is possible for a web browser to cache in RAM only, and also because the cache can't be relied on the same way as most files you've saved manually, because browser caches, like caches in general, are subject to invalidation, where whatever stuff in the cache seems least valuable to retain (based on some cache invalidation policy) is removed automatically when room in the cache is needed for other stuff.
In contrast, information stored for branches like origin/master in your .git folder does not get destroyed automatically. Nonetheless, the analogy partly holds in that it is neither supported nor (pardon the pun) remotely a good idea to attempt to change its contents.
 
3:36 PM
hopefully your remote tracking branches will be more reliable than browser caches...
 
I am inclined to reply to that with a resounding "yes, of course they are"... but what do you mean by reliable?
Like, the remote can totally change, especially by having more commits than there were before, and branches pointing to later commits that didn't exist before. When you examine a branch like origin/master, you're examining your local version of the branch, which may well be out of date.
Fetching makes such branches no longer out of date.
 
I mean to contain the things that were put in them and not lose them unexpectedly
 
Yeah, it does not lose them unexpectedly. So long as you don't expect it to keep things that aren't on the remote anymore.
 
:)
 
If you run git fetch now, it'll connect to the remote, but there will happen to be no changes, so nothing will change.
(But I encourage you to try it anyway.)
The first thing I should have suggested you do after cloning, actually is to run:
git status
Because that shows some information about your remote.
 
3:40 PM
@EliahKagan there was a small delay and no output
 
Yeah, that delay was probably it connecting to GitHub and retrieving information.
 
zanna@toaster:~/playground/hello-world$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working tree clean
@EliahKagan it was a satisfying delay. I could tell whatever was supposed to happen was happening
 
:)
The information it shows may become stale; unlike git fetch whose entire point is to bring your repository's knowledge of branches on a remote completely up to date including all new commits, and also unlike git remote show ... (where ... is some remote), which updates basic information about the remote but does not download new commits, running git status does not communicate with a remote repository, it just tells some information that is locally known.
@Zanna Can you go ahead and make a change on the remote? (You can do this through the GitHub interface, as you did before.)
 
git fetch is an exciting command!
@EliahKagan I'll do that right now
 
@Zanna It will be even more exciting when there's something to fetch!
 
3:50 PM
hahaha
ok, I made a new file on a new branch
 
Okay.
git fetch won't change origin/master, then, since you haven't changed that yet. But it will fetch the new branch.
So please go ahead and fetch.
 
$ git fetch
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com/ZannaStar/hello-world
 * [new branch]      short      -> origin/short
 
So, right now, your local branch master is connected to origin/master. This is to say that master set up to synchronize with origin/master. You'll see what that actually means soon.
I had been thinking you'd make a change on master which would show that. But there's no need to see that first. You created a new remote branch, which is an opportunity to see how to bring that relationship -- between a local branch and a remote branch -- into being.
One way of bringing that relationship into being, you've seen already. You clone the repository and master was connected to origin/master. Specifically the way that was automatically achieved was that the master branch was checked out for you automatically (by default, git clone checks out a branch, after cloning a repo).
 
ohh
 
So you can probably guess that a way to set this relationship up yourself is to check out the branch yourself. And you'd be right! The is the most common way it's done.
Try:
git checkout short
Note that you're checking out short, the local branch that doesn't yet exists but will be created automatically, and connected to origin/short, by the checkout.
 
3:57 PM
$ git checkout short
Branch 'short' set up to track remote branch 'short' from 'origin'.
Switched to a new branch 'short'
 
Nice.
 
exactly what you said would happen :)
 
Can you make some additional changes, on the short branch, through the GitHub interface?
 
will do
 
After you make those changes, run git fetch.
Actually, I suggest you try running git status, then git fetch, then git status again.
 
4:03 PM
zanna@toaster:~/playground/hello-world$ git status
On branch short
Your branch is up-to-date with 'origin/short'.

nothing to commit, working tree clean
zanna@toaster:~/playground/hello-world$ git fetch
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com/ZannaStar/hello-world
   0c4612c..43b17b8  short      -> origin/short
that is interesting!
 
The first thing you've probably noticed is that git status indeed does not retrieve updated information from a remote.
The second is that, as you would totally expect, git fetch fetches commits from remotes you already had branches for as well as those you didn't.
So now origin/short on your machine is up to date with short in your GitHub repository.
However, running git fetch does not automatically put the new commits to origin/short into your local short branch.
Can you think of how this might be achieved?
I mean obviously you can Google it. :)
Hint: you've updated one branch to include changes from another branch before.
 
well, it says "use git pull"
 
I urge you not to do that yet.
You could of course.
The reason is that git pull does the fetch and then then the merge.
 
@EliahKagan by merging
 
You've already done the fetch, so all you have to do is the merge.
Indeed.
So, you can specify origin/short as the source of the merge, but it is actually sufficient to run:
git merge
 
4:10 PM
@EliahKagan oh right, so at this point git pull would be partly redundant, but I wouldn't have realised that
 
It wouldn't quite be redundant, in that it would do another fetch, and if there had been changes between the original fetch and when you ran git pull, you may not have expected them.
 
zanna@toaster:~/playground/hello-world$ git merge
Updating 0c4612c..43b17b8
Fast-forward
 list | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
zanna@toaster:~/playground/hello-world$ git status
On branch short
Your branch is up-to-date with 'origin/short'.

nothing to commit, working tree clean
 
When you want to fetch and merge and you don't want to bother checking what's fetched first, just run git pull. When you want to fetch, check, and then (presumably) merge, run git fetch, do whatever you want to do (which might even be just inspecting the message), then run git merge (or git merge with an argument if you prefer). Either of those is totally fine. Some people say it's better to fetch and merge separately but most of the time I just run git pull, as do many people.
It's specifically running git fetch followed by git pull that should not usually be done, because git pull doesn't quite always do the same thing as git merge even after a fetch, in that git pull may fetch additional changes and merge them unexpectedly.
It's only using git pull when you mean git merge that I'm trying to discourage. git pull instead of git fetch followed by git merge may well be what you want to do.
 
sure, that totally makes sense
 
Now, with that said, it's common to have an editor or IDE with git integration, or a graphical git client like GitKraken, to fetch automatically, like every minute or so.
So you could fetch, then be about to merge, and that fetches again, and your merge merges additional commits.
 
4:17 PM
which could be confusing
 
Nonetheless, I wanted to clearly convey what git pull does and why people sometimes fetch and merge separately. Plus, you will typically know if you have automatic fetching happening.
Personally, I always enable automatic fetching when it's convenient to do so.
Not when just using git from the command like, but like, in vscode, which integrates with git automatically (by running git commands behind the scenes; it's not its own client, per se), I have it fetch automatically.
So if you do run git pull now, no changes will be made because there's nothing to fetch, and thus nothing new to merge.
But I still suggest doing that.
Then I suggest making another change through the GitHub interface and running git pull.
 
it pauses satisfyingly and returns Already up-to-date
 
Right. That's actually the output from the merge.
Like, try running:
git merge
Since there's nothing to merge from origin/short, it will show that message.
(This should also answer the question you may have had as to why git fetch showed nothing when there were no remote changes.)
 
@EliahKagan I merged the short branch and deleted it
$ git pull
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
From github.com/ZannaStar/hello-world
   9b76d2b..294c8e8  master     -> origin/master
Your configuration specifies to merge with the ref 'refs/heads/short'
from the remote, but no such ref was fetched.
 
What's the output of:
 
4:23 PM
@EliahKagan yes :)
 
git branch -a
?
 
zanna@toaster:~/playground/hello-world$ git branch -a
  master
* short
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/short
that has some colours
 
@Zanna That was a somewhat more complex change than I had in mind for seeing how git pull works. :) It works though, in that if you check out your local master branch, you'll be able to see the changes in it, even without running git merge.
@Zanna That's the normal color scheme.
@Zanna That still lists origin/short even though the remote doesn't have it. And you still have a local short branch. You probably don't want origin/short anymore, since it doesn't actually exist on the remote. You possibly don't want the local short branch either.
 
@EliahKagan I used to drive my French teacher crazy by making excessively ambitious arbitrary examples
 
That's excellent!
 
4:28 PM
@EliahKagan right, I've totally messed it all up :D
 
Nothing's messed up.
This is normal. You can prune the remote branch in your local repository. It's a good idea to pass --dry-run first to see what would be pruned.
git remote prune origin --dry-run
If that looks good you can drop the --dry-run option.
Then if you want to delete the local branch, you can do it by checking out some other ranch (so you're not trying to delete the branch you're on) and then using the -d option to git branch, with the branch you want to delete as an operand. The more dangerous -D option should not be needed because the branch is fully merged.
This blog post is a good "cheat sheet" for this situation. (Well, fairly good. It relies overly on images.)
 
zanna@toaster:~/playground/hello-world$ git remote prune origin --dry-run
Pruning origin
URL: github.com/ZannaStar/hello-world.git
 * [would prune] origin/short
zanna@toaster:~/playground/hello-world$ git remote prune origin
Pruning origin
URL: github.com/ZannaStar/hello-world.git
 * [pruned] origin/short
zanna@toaster:~/playground/hello-world$ git branch -a
  master
* short
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
zanna@toaster:~/playground/hello-world$ git checkout master
 
Wait, it's not?
Okay...
I'm no sure what's going on there.
Anyway, you can check if it's safe.
Verify that git status says master is up to date with origin/master (no need to fetch for this).
Assuming it is, check the diff between short and master.
 
$ git status
On branch master
Your branch is behind 'origin/master' by 3 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

nothing to commit, working tree clean
 
Oh.
 
4:34 PM
makes sense
 
So, you should merge into master...
...but this is an opportunity
 
:D
 
...to see how git diff works to see differences that haven't been merged from a remote
I emphasize that this is not really helping with getting rid of short safely, just something I had meant to show you with short before you deleted it on GitHub that I can now show you with master instead.
(You can probably also even do it with short since you do still have origin/short, but it's not up to date--to be up to date, origin/short in your local repo would have to... not exist anymore. :) )
 
I can create more things and not hastily delete them if it would help
 
@Zanna Yes, but I suggest we get rid of origin/short first.
 
4:36 PM
sure
 
@Zanna So actually, for seeing the differences between a remote branch and what you have, try this out:
git log origin/master
 
that shows perfectly how we're 3 commits behind
 
@EliahKagan Btw I should absolutely not have said that after running git pull while on short you would get changes merged from origin/master into master. That's not how git pull works, ever. When I figure out what I was thinking, I'll let you know.
 
although I need to work on writing useful commit messages
 
@EliahKagan (git fetch fetches everything from a remote, but git pull only merges the current branch.)
@Zanna Are the ones you use now bad?
 
4:43 PM
the ones I wrote in my recipe repository were ok. These ones are not illuminating, but it's ok.
 
@EliahKagan I figured out what I was thinking. Originally I thought, for some reason, that you were on master locally. Then when I found out you weren't, I stapled some deep and profound wrongness into my message. I was thinking about the situation where you were on master, pulled but didn't examine the result, changed branches, deleted the short branch remotely, fetched either as part of a pull or otherwise, and then were interested in the master branch. But that wasn't your situation.
@Zanna I'm sure they're at least not as bad as that chat message.
Because that would be impossible. :)
Okay, so, I encourage you to try git diff between origin/master and master.
 
it's pretty complicated. Has to be hard to predict everything that could happen without having the thing in front of you
 
Yes. I'm not frustrated with myself for most of my errors or mispredictions so far. :) I am only trying to call attention to (and also apologize) for the inadvertent claim that git pull merges into multiple branches. It doesn't do that and it's a source of massive confusion because people who've just started using git often assumes it does. Amplifying that confusion would be very bad.
Part of the confusion, in general, is that you can run git pull --all, but that also does not merge anything but the current branch. (What's going on with that is that git fetch --all fetches from all remotes rather than just the default remote, which is useful because you can have multiple remote set up for the same repository. Running git pull --all causes git fetch --all to be run for the fetch, but it still just merges to the current branch after the fetch.)
 
@EliahKagan earlier we were using this command, but I forgot the details of the different ways we can use it. I sort of half guessed that we can compare some branch to the one we're on by passing the name of some branch as an argument, so this is what I did and what I got
$ git diff origin/master
diff --git a/list b/list
deleted file mode 100644
index cf9731d..0000000
--- a/list
+++ /dev/null
@@ -1,7 +0,0 @@
-J
-L-A (ml)
-S (tbg)
-S (Pm)
-VJ (Sd)
-
-
 
@Zanna Oh, the various syntaxes for git diff?
I should be able to find the chat messages about that.
 
4:49 PM
I just pasted into the shell when I intended to copy the output O.O
that could have been horrible
 
@EliahKagan Actually it may just have been:
Aug 2 at 12:19, by Eliah Kagan
@EliahKagan Often git diff is useful with arguments, to see what changed between specific commits (or between a specific commit and the current index, if you only pass one argument). But it's also used to see the difference between the current state of your working tree and your index.
@Zanna I have done that hundreds of times.
It is indeed scary and bad.
 
@EliahKagan yes, thanks!
I think it may be a sign that I should go to bed :/
even though we are on a roll
 
@EliahKagan There is some terminal program (for some OS) that actually warns when you attempt a paste that seems like it's a mistake. It examines the contents of what's being pasted, possibly only for length and number of lines. I don't remember what that is though!
 
wow cool!
 
@Zanna If so, then wakeful you is less accident prone than wakeful me. :)
@Zanna It's up to you. I mean, the stuff in git repositories will probably be okay... :) :)
 
4:53 PM
oh that's unlikely
 
@Zanna Yeah. I'll let you know if I figure it out.
 
@EliahKagan haha great
I'll go to sleep now and come back when I can
thanks so much for your help
 
@Zanna Okay!
When you get back (or whenever), you can run git merge on master to bring it up to date with origin/master (with the information that your local repo currently has for that).
 
ok :)
 
Or run git pull on master to pull anything new, though I don't think there's anything not fetched.
Or run git fetch to fetch anything new (though I don't think there's anything) on master followed by git merge.
After that, you can see what the deal is with short by running:
git diff master short
I don't know what order you'd want to specify the branches in, but I'd do it that way because the idea is to see what's new in short that's not in master, if anything, since that would be an indication that you shouldn't just delete short.
Of course, you see the same information with git diff master short as with git diff short master, but the +es and -es are reverse. I think git diff master short is a more intuitive way to look for actual file contents that may be in short but not in master.
Alternatively, maybe git log (with or without arguments) will show that they're on the same commit, or otherwise shed light on the situation.
 

« first day (718 days earlier)      last day (121 days later) »