« first day (710 days earlier)      last day (1857 days later) » 
09:00 - 13:0013:00 - 17:00

13:00
To see the syntax for doing so, run:
git status
But the syntax it shows you is more verbose than you will sometimes need.
Like, to discard the changes to TO-TEST/TomatoChutney and restore the committed version, you can run:
git checkout TO-TEST/TomatoChutney
Or to discard all changes, which is the same thing if that's the only change, you can run:
git checkout .
This is most often done to undo changes you've just made but not staged or committed.
But it also applies to the situation of getting rid of changes that are left over after a git reset.
I see, so in the current situation, the change is still there even though I've undone the commit
(reset, not revert, sorry.)
got it :)
@Zanna Right, just as it was there just before you did that commit.
@EliahKagan it says (use "git checkout -- <file>..." to discard changes in working directory)
13:04
Yes.
That totally works.
But unless you're checking out a file whose name is the same as that of a branch or something, you can use the simpler syntax too.
The idea is that, by default, you are checking out from HEAD.
I checked it out, and it's back the way it should be
But the first non-option argument after checkout could be taken to be the name of a branch, commit, etc.
If you pass -- as an argument to checkout, then what comes before it is where you want to check out from (a branch, commit, etc.) and what comes after it are paths to check out.
You can omit the paths, in which case all you've done is clarify that you're specifying the name of a branch, commit, etc.
You can also omit the name of the branch, commit, etc., in which case it defaults to HEAD.
@Zanna Excellent.
So I had said I'd show this with a deleted branch but this is actually an opportune moment to try using the reflog to recover something that's been "lost."
git reflog should show the commit that is no longer shown in the output of git log due to the git reset` operation.
You can specify that commit by its hash in git operations.
I suggest checking out that commit and verifying that the change is there.
Then you can check the branch back out and verify that it's not there.
(To actually recover the commit for practical use, you might make a new branch from it.)
After you try that out -- or instead of trying it out if you don't feel like doing so -- I think I should show you what git reset with no arguments is for.
@EliahKagan Ooh, the other thing you should do is run:
git diff ...
where ... is the hash of the commit that disappeared from the current branch (i.e., is not shown in git log), gleaned from the reflog.
When you run that from the tip of the current branch, it shows the changes from that commit to the current state. That's actually useful, if you're unsure if you accidentally lost too much in a reset or other operation that rewrites history.
@EliahKagan oh yeah!
@EliahKagan and it's not
cool!
I actually made a mistake when I ran git reset ...
How so?
Oh. You mean you passed ... literally?
in that I reset to the commit before I made the unnecessary change that I reverted earlier
13:16
Oh.
Well you can fix that problem! :)
@EliahKagan no
@EliahKagan :D
Oh.
Well, assuming you want to fix that, you can reset back, or (though this is a strange way to first do a merge) you can merge from the commit whose changes you want to keep.
so what I did was reset too much
The latter is what I would actually do, because I reset as seldom as possible, because it's so easy to make mistakes! :)
I only realised I had done that when I checked out the New branch after checking out the file I wanted to undo the change to
it told me:
$ git checkout New
Warning: you are leaving 3 commits behind, not connected to
any of your branches:

  32d2a35 Carelessly overwrote the contents of a file
  75a98a9 Revert "Added an unnecessary line to a file, for science"
  9228522 Added an unnecessary line to a file, for science
so, I don't really need those 2 commits before the one I really wanted to reset
but let's get them back anyway like you suggested
@EliahKagan yeah, messing with history is a bit scary
13:22
You haven't made any changes since the last reset, so you can just run reset again to undo it or to reset to where you actually want to be.
Have you managed to fix it?
yes
I reset to the right place by looking in reflog
and everything is how it should be
and I am getting working tree clean
You could also have run git log from the most recent hash (assuming you know it or get it from the reflog) and figured out the other hash you wanted to reset to from there.
You could do that a detached head state but you could just pass that hash (or a unique prefix of it) as an argument to git log.
:)
13:32
So, to see what git reset with no arguments is for, try making a change and staging it but not committing it.
Aug 2 at 11:40, by Eliah Kagan
@Zanna Git is great for that! :)
I can see Git is the thing for me hahaha
@EliahKagan ok :)
Well there are other source control systems.
@Zanna Then run git status.
You can unstage changes selectively using commands like what it suggests. But you can unstage them all with:
git reset
This resets your index (i.e., what's staged).
When I set that what git reset ... does is to reset HEAD is not all git reset is for.
And actually, git reset with no arguments is a fairy common use.
just never ever do git reset HEAD :D
13:36
@Videonauth Why not? That's the same as git reset with no arguments.
In most cases it only messed up my repo extremely
afaik, please correct me if I'm wrong it resets as well the complete history and can end up your git in an unstable/undesired form
@EliahKagan I can see why I'd want to do that
(I meant to say fairly common. :) )
@Videonauth git reset is dangerous because it rewrites history if you use it to reset to a specific commit (that doesn't happen to be the one you're on). But I believe git reset HEAD, like git reset with no arguments, just resets the index to match the current commit, which is to say that it unstages staged changes.
mhmmmm
@EliahKagan I guess fairies have magic to undo their mistakes, so they don't need source control
13:40
@EliahKagan I never run git reset HEAD so I don't feel 100% sure, but that is the syntax that the output of git status recommends for unstaging (though it suggests specifying individual paths to unstag).
@Videonauth If do you do bad thing with git reset commands in which you specify a hash, tag, or branch to reset to, and you don't subsequently commit, you can undo the damage by resetting back to the commit you had been on before, whose hash you can obtain from the output of git reflog.
Even better is to use git reset as seldom as possible, at least for that sort of usage. :)
If you do commit after git reset and then need to undo all or part of the reset, then... oof.
ah as we speak of source control, let's say you have a git of something cloned to your drive and maybe even forked it on GitHub, you can set your local branch to have an upstream master with git remote add upstream master <url>. then you can issue for example git pull upstream master && git push to update your fork.
@EliahKagan But in that situation, one approach that I think is sometimes appropriate is to merge from the hash of the commit that was at the tip of repository before the reset.
@Videonauth Yes.
O.k. then I seem to be at a misconception here. I messed up once with it and after that avoided git reset like the plague.
^^^ @Zanna I hope we get to setting up your repo with a remote today if you're up for it.
@Videonauth Well, being afraid of reset is still a fairly reasonable conclusion IMO. :)
I know I fear it.
it would be good to try that!
Now I need to go and do some housework things
I'll try to get it done quickly and come back
13:47
@Zanna Okay, so we've covered revert and reset. Normally I use, and would advocate, revert over reset for taking the tip of a branch back to where it was one commit ago. However, in the situation of feature branch where the master branch is one commit ahead of where you'd like it and was that way when the feature branch was created from it, there is an argument for using reset.
@Zanna Understood.
I suggest picking up from the situation with your master branch having those two extra files in TEST/ that currently belong only in the feature branch New.
@Zanna Well, you shouldn't rush on my account. I may well be available but I cannot guarantee it.
@EliahKagan oh, so you think reset would be the better way to get those files onto the right brance
I'm looking forward to continuing, though.
@Zanna In this specific case, yes, but I'll want to tell you what the issue is and then you can decide. When we continue, I will.
(If you want me to tell you now, I can do that, but I know you need to go afk for a bit.)
it wouldn't matter at all if you were not available :)
Indeed.
I'm not sure which of the two meanings of that you intend, but I agree with both of them.
hahah
13:51
(That I don't need to worry about being [un]available, and that you can continue with Git in my absence.)
I meant the first one
The second one is also true!
@Videonauth Btw I joined the ProtonDB Discord server.
@EliahKagan oh cool, if youre running in trouble just holler :)
@EliahKagan I am going to think about it and see if I can figure anything out. The nice thing about housework is that you can do it with your brain tuned to another channel
thanks so much for your time so far!
@Zanna Well, it has to do with a concept that is important but that we haven't yet covered.
13:54
hmm :)
that's ok
@Zanna It has been helpful to me as well, for example when I realized I wasn't at all confident in my knowledge of what the count of insertions or deletions actually meant and didn't know how binary files were treated in terms of those statistics.
@Zanna But I can say the word for that concept right now and then you will likely think of the relevant issues.
I would just do that but I fear you really don't want spoilers or something. :)
I recommend you let me say the word.
haha yes, do that!
indeed, an evocative word :D
@Videonauth Thanks. I'm Sir Griswold of MacElwain (full info in my AU profile).
I mean that's my name on Discord. My actual name is Eliah Kagan. :)
14:05
:)
snt you a friends request
Accepted.
just watching a small doku of a day which i can't forget tho
sadly in German. but if you want to know what it is google for rammstein air show 1988
I was unbelievable lucky that day
If i not have had went into a tent to get me a new beer i would probably been dead
I did not know about that.
I got spared from the fireball and had only hard sunburn like symptoms due to the military tent
I'm glad you were okay!
14:11
but the tent was gone after that initial fireball has hit it
and around me was chaos pure
 
2 hours later…
16:16
I also did not know about that O_O
@Videonauth so beer possibly saved your life XD
I am going to go to bed as it's already so late :(
@Zanna yes it did
Maybe I will have some more free time tomorrow
if i would have been outside that tent i would have been burned to a crisp
like the 70 very unlucky persons outside that tent
Yeah :(
Happy you made it
me too, i even helped until late night tending the wounded as i was a youth paramedic in my hometowns voluntary fire brigade
but its a sight you never forget and which haunts you even from time to time
09:00 - 13:0013:00 - 17:00

« first day (710 days earlier)      last day (1857 days later) »