Advanced Git (And GitHub)

30 September 2014

A walkthrough of some useful but rarely known features in Git and GitHub.

Presented at ScotSoft in 2016, JavaOne in 2014, TechMeetup Edinburgh in 2013 and DunDDD in 2012.

Show transcript

0:00 Hello everyone, quick introductions, I'm Mike, this is where you get me on the internet.
0:12 So I've been using Git for too long, since about 2006, and I like to kind of fight it
0:19 and things like that.
0:20 So who here would say they know Git well?
0:23 Who here has to use Git at some point during their job or uni or whatever, pretty much everyone
0:32 okay, so this is the very small group I'm interested in, who thinks, and this isn't a challenge,
0:38 who thinks they probably won't learn anything from this talk, because they know everything
0:42 about Git?
0:43 That's disappointing.
0:45 Right, so this talk, I don't know if you guys followed from whatever was going on with
0:52 to tag me up, but I was kind of pulled in at the last minute.
0:55 So this is sort of snatched from a previous talk.
0:58 So if the slides appear to make confusion, then that's why.
1:04 It was previously following on for a kind of beginner's Git talk.
1:07 So I'm going to sort of recap what would have been the beginner's Git talk very briefly, and
1:12 then kind of move on from there.
1:14 So the first thing is, if you're not using it already, I really recommend there's a tool
1:19 called Gitx if you use a Mac or GitK if you use Windows or Linux or have no sense of aesthetics.
1:25 No, that's not saying those platforms are, but for anyone who's run GitK, you know what
1:33 I'm talking about.
1:34 Right, so basically, that's something I found really helpful in Git, because instead of looking
1:39 at your logs or whatever and trying to understand, oh, when did that branch branch off this and
1:43 all this stuff, you can get a nice little view like this.
1:47 You can see here, I've got these 0.1.
1:50 That's a tag.
1:51 That's a branch.
1:52 That's another branch.
1:53 That is a merge and a branch that no longer exists.
1:56 There you go.
1:57 So that's basically the kind of overview for it, particularly when you have a repository
2:01 where you start having branches off branches and lots of coworkers working on lots of different
2:05 things all at once and pull requests, some of which have merged and some of which aren't.
2:09 This becomes very useful in working out.
2:11 Have we actually merged that bug fix from two weeks ago or is it still away floating somewhere?
2:17 Because particularly with stuff like this, anything that sort of, this is a bad example,
2:22 this is a straight hierarchy, but if, say, we didn't have this little blue line joining
2:26 here, then that would be effectively a floating which doesn't actually belong anywhere and
2:33 it's not been merged back anywhere.
2:34 So then we would know that we need to merge that on.
2:37 Git describe, very briefly, one of these things you may or may not know about.
2:40 It's kind of useful in getting sensible version numbers.
2:42 We call it git describe dash dash tags.
2:44 Then on the last one, I will get these 0.1, which is the last tag, dash two, two commits,
2:50 and then the current short hash code where we are.
2:54 So the nice thing about that is because the way it's arranged as well, they sort nicely.
2:58 So if you have any software where, say, you're doing builds automatically and you want users
3:04 or testers to be able to report a version number back, that's a good way of generating it.
3:08 Finally, git ref log.
3:10 Who has or has not, sorry, who, that's not helpful, who has used git ref log before?
3:16 Not enough people.
3:18 Git ref log is one of the first things you should be taught with Git.
3:20 Because with Git, the thing that tends to scare the pants off everyone
3:23 is the idea that you can go around rewriting history and then when people hear that,
3:27 they think, oh, I'm going to accidentally do something and I'm going to destroy all my work
3:30 and destroy all my co-workers work, destroy the company and the economy and everything.
3:33 But with git ref log, you didn't interfere.
3:36 Because what git ref log does, I presume pretty much everyone's familiar with git log,
3:40 which will go and list all the commits on the current broad shore.
3:43 What git ref log does is effectively does the same thing,
3:46 but for all the changes you make to the head pointer.
3:51 So, a little bit of confusion there.
3:53 I'm not going to go into too much detail about what the head pointer is,
3:55 but head pointer is basically the current state effectively of your git repository.
3:59 So, if I run git ref log and I've done some stuff,
4:03 you can see here it's kind of tracking through.
4:05 So, merge testing, I merge that, I made a commit and then I did a reset and a commit there again.
4:11 So, the interesting thing here is this part number two is me rewriting history.
4:16 So, I made one commit and then I made another commit later on,
4:19 which may have the same name, but it's a different commit.
4:22 So, even though I've actually gone through and modified this commit,
4:28 if I look in the history, if I look in git log or git x or whatever,
4:31 then I won't see any evidence of this at all.
4:34 I can still get back to that state at any point in the future,
4:37 using the git ref log to go and find out where these things are.
4:41 So, I would really advise you,
4:43 particularly if you're going to do anything involving rewriting history,
4:45 if you're worried, just run git ref log and then you can go and jump back to any state.
4:49 Basically, I think it tracks 30 days worth of state before Git will garbage collect any of that.
4:54 So, effectively, all the actions you've done in the last 30 days will be there in ref log.
4:59 So, fear not.
5:01 Right, git blame.
5:05 I presume you know about that, but that's, basically,
5:08 if you want to blame something on your co-workers, you think,
5:10 "What idiot wrote this line here or whatever?"
5:13 So, you can go and shout them.
5:15 In my experience, at least 50% of the time I run that,
5:18 I find that the idiot was actually me.
5:20 Which is a little bit embarrassing and I tend to go a bit quiet.
5:25 Get SVN.
5:26 So, what percent of the time does the opposite happen,
5:28 where you go back and it's like,
5:29 "Oh, who wrote this clever little feature?"
5:31 "Oh, lucky it was my past self."
5:32 Well, sorry.
5:33 In subversion, I think there is subversion praise, which would do the same thing as blame.
5:38 But Git doesn't have praise.
5:40 It just has blame.
5:41 Which, that might tell you something.
5:44 All right.
5:45 Get SVN.
5:46 I'm not going to go into detail about this, but basically,
5:47 Git has the ability to interface with an SVN repository.
5:52 It's quite useful if, say, you want to kind of learn Git, but you're somewhere where either the current project you're on or the company you're at or whatever is still using subversion.
6:02 Then this basically lets you, you can do all the kind of cool Git magic locally, and then it gets pushed to a subversion repository.
6:08 So you can't rewrite history on the remote repository.
6:11 Generally, that's a bad idea anyway.
6:12 But you can do all this kind of cool stuff locally and deal with Git's branches locally, rather than with subversion's horrific branches.
6:19 Git rebase.
6:21 Again, we'll come into a bit more detail about that later on.
6:24 But effectively, rebasing is when I say I have a certain commit and I want to go and...
6:32 So with Git, all the commits, I'll jump back here, have parents.
6:39 So the parent of MerchBond's testing's commit is...
6:43 Well, it has two parents, in fact.
6:45 So I won't start with that one.
6:46 Testing the parent of that commit is this one, change license here.
6:51 And then the parent of that is this one here.
6:53 And then when you have a Merch commit, you have a commit which has two parents.
6:56 So we see these two lines joining up.
6:58 So basically what we have with rebase is it's a way of rewriting history that's relatively common to do,
7:06 which is basically you update the parent of a commit to point at the parent of something else.
7:11 So this would maybe be better named re-parent instead.
7:15 So that's kind of useful, particularly if you are doing, for example, an open source.
7:22 You will use that often because what you tend to have is, you know, if I have my branch that I want to submit to someone else's work,
7:28 they probably don't care about the fact that I've had to merge back and forth 800 times.
7:32 Their changes back to mine, my changes back to theirs, whatever.
7:36 So you can use rebase to effectively kind of clean up their history, fix merge conflicts and things like that by ensuring that the parent commit is always at the top.
7:47 Right.
7:48 This is a little shortcut.
7:49 Not many people, well, some people know either, some people don't.
7:51 If you git checkout -b testing, that effectively does the same thing as creating a branch and then checking it out.
7:58 So that's a little shortcut.
7:59 Git reset -b test hard is that will basically go and change your history at the moment so that your head pointer, effectively the top point of where you are in git, will point to the commit you specify at the end.
8:15 Now, this is pretty dangerous as you might be able to tell by the dash dash hard.
8:21 So what this will do is effectively anything in your working tree, like anything you haven't committed yet, will be destroyed if you run this and you haven't saved it.
8:30 So in git -treat -saving, instead of saving you can think of committing effectively.
8:37 As I showed you with the ref log before, if something is a commit, it has a shell on and basically you don't need to worry about that for 30 days.
8:45 That you effectively can't lose that unless you try really hard.
8:49 So what I would encourage you to do if you're doing stuff with git, particularly if you're doing rewriting history, if you're doing lots of incremental progress during the day and stuff like that.
8:57 And if you're the type of person who likes to have nice clean commits or the type of person who likes to have one commit for their day's work rather than 800 commits, then commit lots during the day.
9:06 And then either combine the commits or reset or whatever and then kind of build stuff up later on, which you can then combine and push on.
9:14 Because then that means if you need to jump back your progress from what you did four hours ago, whatever.
9:19 And again, talking about personal experience, I'm always one for thinking like, "Oh, yeah, like, oh, that stuff I did this morning, I'm never going to need that ever again."
9:29 And then half an hour later, of course, I'm like, "Oh, why enough did I delete that? I've wasted so much time."
9:34 So if you continually commit the stuff you're doing, it doesn't matter, you can go and get rid of it later on, git will clean it up eventually, but you don't need to worry about losing it.
9:44 Right, so I'm going to run through some slides briefly, one second.
9:54 Right, so to demonstrate the rebasing I was talking about a minute ago, sorry again, this is where it gets a little bit messy order.
10:02 So the normal program will resume shortly.
10:05 So if I want to, I have this commit called first point that I just made here.
10:12 So that's got the hash 9f blah, blah, blah, blah.
10:15 So if I committed that on what we had previously on the testing branch, then the history would look something like this.
10:20 And you can see testing and master have diverged at this point.
10:23 They were in common here, and then they're not anymore.
10:27 So these now have separate things on them.
10:30 If I then type git rebase master on the testing branch, it will say in helpful gitties, git almost never says anything in the language that humans can understand.
10:40 Rewinding head to replay your work on top of it.
10:43 Applying first point.
10:44 Right, what does that mean?
10:47 What that means is that the head, which is currently where I'm on testing here, that's the branch I got checked out.
10:53 It's rewinding that, so it's jumping back, because I said master, jumping back down to here, and then going back up to here.
11:01 And effectively what it's doing is just getting rid of this stuff in between, storing it elsewhere, and then when it gets here, it's going to try and put these commits on top of it.
11:09 Which, in this case, because we don't have any merge conflicts, you get this.
11:14 So to jump back between them again for a second, we have first point.
11:18 So the only commit that's not on master, but is on testing, is its first point.
11:24 So in rebase here, it kind of adjusts the history so it looks like this.
11:29 Again, you might think, why on earth would I ever want to do that?
11:32 But particularly if you're someone like, in my other life outside of work, I work a lot of homebrew.
11:40 And at homebrew, we get contributions from thousands of people.
11:44 So we don't want these horrible little merge commit jumps like that for every single contribution we have from everyone who's not in the core team.
11:52 Because that would be 95% of our contributions.
11:54 And then our history, which should look nice like this, would be completely unreadable.
11:58 So rebase effectively allows us to go and make sure that these commits follow a nice, fairly linear history, unless we have something where we actually want to effectively record in the history that we've had a branch.
12:10 I'll talk a little bit more about that in a minute.
12:14 Right, git bisect.
12:16 Git bisect is awesome.
12:18 What it does is effectively does a binary search through your git history to find where you had a particular bug.
12:24 So let's demonstrate here.
12:26 So this will be a very simple use case.
12:28 So basically, say I have a bug that is in my current version of the application.
12:33 I know a previous revision in the version control system where that bug was not there.
12:37 So while we type git bisect start, that kind of kicks off the process.
12:41 Git bisect bad master, that's saying not that your boss is a nasty person.
12:47 But saying that the top of the master branch is bad.
12:51 That doesn't work.
12:52 And then git bisect good and then specify a revision that does work.
12:56 So then it's saying bisecting 55 revisions left to test after this, roughly six steps.
13:01 So then what I will do is basically just go through a bunch of commits.
13:04 Like good, bad, etc.
13:07 And then eventually it will go and iterate through these and it will tell you the commit which has that problem in it.
13:12 So particularly if you're dealing with lots and lots and lots of commits, obviously because it's a nice fast binary search.
13:18 It means actually this is really pretty quick.
13:21 And I use this on a relatively regular basis to try and track stuff like regressions.
13:25 But when it gets even cooler is git bisect run.
13:30 So in this case, I have a situation where I have a particular, let me check, yeah.
13:40 Okay.
13:41 So in this case, say I have a particular test, which is this spec mailers newsletter spec.rb.
13:47 So what I can do is I can use git bisect run and then I can effectively give git bisect run the actual test.
13:54 And if you know about Unix exit codes, good.
13:59 If you don't, you might struggle with this a little bit.
14:02 So effectively, as long as your command, which most things do, to be honest, returns the right exit code by a zero for success and a one for failure or a non-zero version for failure,
14:15 then it will go and run through that process rather than you having to type good, bad, good, bad, good, bad.
14:20 It will then run through that process automatically, run the command, check out another revision, run the command, check out another revision.
14:27 So if you have a way of breaking your error effectively down to a specific test, then this will run through and kind of find these regressions very quickly.
14:36 So another good reason to have lots of good tests.
14:38 How do you express what bisect run should run?
14:42 Yes, that's slightly confusing there.
14:44 I mean, you would specify, I've not specified actually the arguments there, but you would specify effectively git bisect run and then just spec mailers, newsletter spec.rb.rb.
14:53 Okay, so it's just an argument.
14:55 So no, in fact what, yeah.
14:57 So what I've done here is not actually running the test because for some stupid reason I decided to pick a stupid example.
15:04 But in this case I've done, I'm trying to find the revision where this was introduced by doing slightly arbitrary, by doing running ls.
15:13 So I would do ls, spec mailers, newsletter spec.rb.rb.
15:16 So then it's going through and runs ls, follow up, no such file directory, that's a bad exit code.
15:22 So then it goes through here and then it finds that this was the commit where I went and introduced that particular file.
15:29 Does that mean you can create a test that retrospectively can see if you know the test was good at one point in the past?
15:36 Yeah, I mean there's no reason the actual specific command you're running, that doesn't have to be tied to your git history at all.
15:41 So yeah, so you could run the commit, you could have a particular test.
15:45 The only thing you would do in that case would be you would not commit that test to the repository yet.
15:50 Or at least have it not committed in the first revision you're checking.
15:54 Because otherwise if it's committed then git will go and delete it and add it and stuff like that.
15:58 So what I would tend to do is just put the test in a different directory of whatever temporarily while I'm running the bisect.
16:04 And then at the end you type git bisect reset to get back.
16:09 So git rebase -i.
16:11 So rebase, bit confusing, rebase -i, bit more confusing but a lot more useful.
16:17 So what I was doing before, I was showing how we could go and queue some commits on top of another commit, reparent them.
16:24 So with that, if I'm queueing these two commits on top of master.
16:29 So I would type git rebase -i master.
16:33 And then it will pop up my text editor, which the first time you run it you're like huh, I didn't expect that to happen.
16:39 And then it will go and list these things here.
16:42 It says pick, it says the SHA1, it says the commit, well the first line of the commit.
16:48 So down here you have a list of all the commands you can do.
16:52 And basically, to walk you through these very briefly, pick just basically means do nothing, use the commit as is.
16:58 What you can do is you can use that to reorder the commits immediately.
17:01 That's something I do quite often if I'm trying to kind of make my commits in some sort of sensible order.
17:06 You know, say introducing certain things before other things and it makes a bit more sense.
17:11 But it's different to the order that I've actually made the commits in.
17:14 Then you can go and just reorder them in here.
17:16 Again, you just cut and paste them in the text editor.
17:19 You can also cut lines out and things like that.
17:22 You can also add in new SHA1s that aren't in here and then it will do the right thing.
17:27 You can use reword.
17:28 That will basically, when it gets to that commit, prompt you to alter the commit message.
17:32 You can do edit, which will, when you get, it will go and, when it's rewinding, when it gets to that commit, it will let you go and edit the contents of that commit.
17:40 Squash will go, I'll explain that in a second, that's basically a fix up and a reword.
17:46 And fix up is the one I use constantly.
17:48 So if you look at my git history typically, it will look, they look nice and clean like this one and done.
17:55 But it will typically look like add newsletter mailer and then fix me, fix me, fix me, fix me, fix me, fix me, fix me.
18:01 And then what I do at the end is I use fix up and I combine all these together.
18:06 Or alternatively, I use squash, which combines them all together and then basically prompts me to edit the commit message.
18:12 And we'll go and display in the editor all the commit messages and all the commit sub-squash together.
18:17 So again, if, which you should do, now that you have git, it's great.
18:21 Because although it solves a lot of problems, you have a new thing to worry about.
18:24 Which is with stuff like subversion or whatever, you know, sometimes you just need to commit stuff.
18:28 You know, you need to get that into production, you need to, you know, do your work.
18:31 You need to get it away so it's backed up somewhere else that isn't your own machine.
18:35 But with git, now that you can control the history, what you should be aiming for is to have a history which is very readable.
18:41 If I ever, I'm lucky enough to work with any of you people and I ever see a commit in git that's called fix me, there's going to be trouble.
18:51 Because you've got no excuse with git because you can go and do that immediately and then go back and edit it later.
18:56 And that's what I would kind of encourage you to do.
18:58 The workflow with subversion I found was a bit more, you know, you do some work, you commit, so that sends it to the repo.
19:04 You do some work, you commit, that sends it to the repo.
19:06 With git, what I find myself doing instead is I will generally only push to the repo maybe once or twice a day.
19:11 And what I will do is I'll kind of queue up all my commits, do all my work.
19:15 And then when I'm ready to push, I'll then go through, read through my history, read through the commits, and then go and basically edit stuff so it's like a little bit more easy on the eyes in the history.
19:26 And so, again, obviously the benefit of this stuff, particularly when we're doing stuff like bisecting, when we're looking through the log, when we're looking through the ref log.
19:34 If you have good commit messages, then it makes these things much easier when you're going back and trying to work out why that idiot, who is probably me, did something six months ago.
19:44 Git Cherry, I'm going to sort of fly through some of the remaining slides because I have lots of slides and not much time.
19:52 Git Cherry basically lets you, if you run it on a branch, it will tell you a list of commits that are on your current branch but not on the other one.
19:59 You can run external commands.
20:02 If you have anything in your path which has like git-gc-global or whatever, it looks kind of like a git command.
20:10 Then you can basically just run git space gc-global and that will run in any directory and stuff like that.
20:16 So that you can extend git with your own scripts if you do that.
20:21 What I was saying earlier about rebasing versus merging.
20:28 This is an example of the cmake virtual system.
20:31 You can see they have a very kind of merge heavy thing where they have all these branches, merge topics, c-test, detect, maven errors, and warn.
20:39 Then they merge everything all together.
20:41 So I think personally their git commit history is really quite hard to follow.
20:47 It's quite hard to tell what happened, particularly because of the way it merges work and things like that.
20:52 If you look at the date column on the side, it's going mental.
20:56 And it's quite hard to work out who committed what, when, who merged what, when, whatever.
21:03 Whereas in Homer we try and have a bit more, like I was talking about earlier.
21:07 So in theory we could have the same kind of approach where we have 800 merges and they're all going around and whatever.
21:14 But we try and kind of keep things nice and linear so it's easier to follow, like individual commits.
21:19 So in terms of preferences, and that comes down to whether you use merge lots or rebase lots.
21:27 In terms of preferences, I tend to, in a small team of people where you want to actually signify something from merge commits.
21:35 So at my current employer, for example, we have, you know, our work branches get merged into epic branches, which then get merged into master or staging.
21:44 So in those cases we want to actually know, like this merged, this bunch of stuff in at this time.
21:51 But if you tend to have a bit more of a workflow where you only have one version, effectively, that you care about,
21:58 you may be branching off that version but you're coming back later on.
22:01 And the history you only care about, a particular branch, then you probably want to use rebase a bit more to clean things up.
22:07 A bit more like Homegroup.
22:09 Commit messages are important.
22:13 What you should have in your commit messages, it's like writing an email, think of it that way.
22:17 The first line should be the short commit message.
22:20 Then you should have a local commit message that can spend multiple lines and do lists like that.
22:24 For example, a good commit message written by me.
22:27 So actually, Git will deal with commits and can convert them to and from emails.
22:34 So if you think of stuff like this, so that would be the first line of my commit here.
22:39 It's used that into the email subject.
22:41 Then we've got some text here, blah, blah, blah.
22:43 And then if you, again, convert it to an email, it goes and has a bunch of tips down here.
22:49 So the main thing to come across, first line should be short.
22:52 If you've got a decent text editor, it will shout at you if it's more than 50 characters.
22:56 And then other lines should be wrapping around about 76 characters or whatever.
23:01 Again, not crucially important.
23:02 But the thing with some of this stuff is because Git's tools are built around these assumptions, and because Git doesn't do them for you, if you don't follow them, then things become a lot harder to read.
23:12 Particularly your main commit message on the first line.
23:15 I would highly recommend you keep that short.
23:18 It makes things much easier to read.
23:21 I'm going to fire through some other stuff very briefly.
23:23 Git filter branch.
23:25 You probably won't use this very often, but if you do, it's good to know it exists.
23:28 Basically what that does is it runs through your entire history and lets you rewrite your entire history.
23:32 So if you had an employee who left and he killed your parents in a freak yachting accident and you want to say, "I don't want to recognize his contributions to my project anymore."
23:41 You can go through and have all his commits rewritten to make it look like you did them instead.
23:47 If you're using GitHub often and you like the command line, I recommend there's a gem, and it's also in Homebrew if you don't like using gems, called hub.
23:57 That lets you do things like hub pull request, which then will create a pull request from the command line.
24:02 It will pop up an editor and basically say what branch do you want to create it from and to, stuff like that.
24:06 And if you create a lot of pull requests, again at my employer and at Homebrew, we use pull requests a lot for a code review.
24:14 Then it makes things a lot nicer to be able to not have to go and click, click, click, click, click through the web interface.
24:19 On GitHub, if you use @ and a username, you can talk to people directly.
24:23 So in here, this dude has said @myMcGrade and he's talking to me.
24:27 That will notify you and, you know, they'll bring you into the thread if you haven't got it already.
24:32 You should get an email notification.
24:34 If you care about stuff like patch files, again, so you can merge them or so you can do Unixy things with them.
24:40 Then if you append .patch to a pull request, which looks like this, or to a commit.
24:46 Then if you append .patch to the web, then you will get a nice Unixy patch file.
24:51 If you do fixes #1, that will then close issue one when you go into it.
24:58 So here I've said it closes this issue here, and then close the pull request from a commit.
25:06 Going towards the end, if you're not.
25:10 svn.github, I don't actually know if it's this URL anymore, but what you can do is you can actually check out, not many of you will notice,
25:18 every GitHub repository you can check out as subversion and commit to it as well.
25:22 They have their own proprietary internal subversion git bridge.
25:26 So you can just do svn checkout, specify the same URL you've used with git, but without .git depended,
25:34 and then there you go, you can use subversion with git.
25:38 Why?
25:39 Why?
25:40 So as much as I like git, particularly for people like designers or whatever, the workflow with git is getting better,
25:49 and there's a lot of good tooling that's been built on top of it, but I think it's still very rough.
25:54 And if you're a developer, it's worth your while learning how to use it.
25:58 I think if you're someone who commits to the first control repository once every couple of months, it's probably not.
26:03 And subversion, I think, is a lot easier in terms of just getting that interface.
26:07 And actually, with what I was saying about git svn before, if you're using GitHub, I would highly recommend this,
26:12 because that means all the git people--so subversion is an easier subset of git's functionality than using git svn.
26:21 So effectively, all the git people get to do all their git stuff in their different ways, and the subversion people can still do basically everything,
26:28 and they aren't limited.
26:30 Right.
26:31 We don't care about that.
26:34 So I would recommend--I know I'm blowing my intro a little bit--if you care about lots of cool little things of doing in Git,
26:41 so I have my .files repository on GitHub.
26:44 If you go and have a look at that, then my git config is really, really heavily commented.
26:49 It explains exactly what I'm doing with all--I've got about 100 aliases and stuff like that to do things like, you know,
26:55 make--commit all my current changes, merge that, and make a pull request in like a single command.
27:02 So if you want to kind of learn faster, cooler ways of doing things with Git, check that out.
27:07 If you want to learn other stuff about Git, check out ProGit's probably the best book that's out there at the moment.
27:12 And GitHub's help is pretty good, and a bit more human readable.
27:18 Or alternatively, contact me, and if you're nice, I might even apply.
27:23 And I know we're a little on time, but if anyone has any quick questions, it's probably good.
27:28 In your intracted rebase, I saw you could delete a line from the commits at the top, and it said that would completely destroy the commit.
27:37 Yeah.
27:38 Is that still there in that 30 days?
27:40 That would still be there in reflog, yeah.
27:42 I mean, that's basically just so people don't accidentally cut a line when I think--get very scared.
27:46 Yeah, reflog's one of these weird things that no one really talks about it, and Git never really talks about it as well.
27:53 But, you know, the assumptions are that it doesn't exist and that you're going to lose all this stuff.
27:57 But as long as you keep that in mind, you'll be safe.
28:00 Any other questions?
28:06 Nope.
28:07 I don't know if I dare broach the subject, but I mean, he's Mercurial in the past.
28:13 Is the only difference, or is the advantage in your opinion, that you can make the commit history more readable?
28:21 Is that the only difference?
28:22 I mean, I've tried to use Git before, and I've used Git here and there.
28:27 Yeah.
28:28 I haven't looked too much into it.
28:30 Because I didn't really see a meet, like a point.
28:34 So you have, like, a reason why I would change from Mercurial to Git other than--
28:40 I've not used Mercurial heavily, so, I mean, what I say is pretty much based on hearsay.
28:45 Right.
28:46 But I've heard Git's a lot more performant.
28:49 I've heard the user interface in Mercurial is significantly better.
28:52 Yeah.
28:53 The Windows version, for example, is significantly better.
28:55 I think, to be honest, it just-- I mean, most of this stuff, not so much in the advanced Git thing,
29:01 but I think the big jump is going from something like subversion to a distributed version control system,
29:06 be it Mercurial or Git or whatever.
29:08 In terms of the specific one you're using, Git's my one of choice.
29:12 That's the one I've poured all my time into, but I'm not really trying to invert people between them.
29:17 I think, unless-- if you work on a project that uses Git, that's a good reason to use Git.
29:21 If you don't, then double it.
29:25 I've tried to convert a really large subversion policy to Mercurial.
29:30 I think, basically, just about a day, I just killed the process.
29:33 But Git did complete, at least.
29:34 It took a while, but--
29:36 But for what it's worth, I was trying to do that in an extremely large SVN repo,
29:40 and I had to dump the entire repo to go through many, many hoops to get it in Git.
29:44 But it is possible, even for, like, a 10-git repo.
29:49 Well, thanks very much, everyone.
29:51 Thank you.

Mike McQuaid

Advanced Git (And GitHub)