Git troubleshooting flowchart
-
It looks like a joke, but is actually a pretty useful reference for fixing git screwups.
http://justinhileman.info/article/git-pretty/git-pretty.png
http://justinhileman.info/article/git-pretty/
Not sure if Sidebar WTF is appropriate category, but I know some folk here feel that anything git related is, so there you go.
-
It belongs here:
(I do not think it means what you think it means.)
Take a mulligan?
DangerZoneTM
-
git resetis confusing to me. It can do too many things, it should be split into separate command in my opinion.I mean, sure, I can read the doc and understand it, but I'll only remember it long enough for me to use it once.
-
The fact such a thing is even necessary is slightly worrying.
-
git reset is confusing to me. It can do too many things, it should be split into separate command in my opinion.
I mean, sure, I can read the doc and understand it, but I'll only remember it long enough for me to use it once.
What I know about git reset:
git reset= Clear up everything you've "staged" usinggit add
git reset --hard= Bring everything back to the way it was last time you didgit pullorgit commitLOSING ANY CHANGES YOU MADE IN THE MEANTIMEI guess you better not screw up that switch, huh?
-
What I know about git reset:
git reset= Clear up everything you've "staged" usinggit add
git reset --hard= Bring everything back to the way it was last time you didgit pullorgit commitLOSING ANY CHANGES YOU MADE IN THE MEANTIMEI guess you better not screw up that switch, huh?
Another reason it should be split.
-
The fact such a thing is even necessary is slightly worrying.
Is needing such a thing better or worse than having one that is roughly, say,
:-)
-
TFS is a bit of a dark art onto itself, but once you learn how fussy it is it is okay. GIT is alright as well, but yeah it can be WTF.
-
The years I have spent with SVN mean I never get to the green box in the first fucking place.
-
So you've never committed while forgetting to
svn addsomething required? You've never committed a partial fix for something, only to soon after realize that it was incomplete and have to do more? You've never started working on something in your working copy, get partway in, and realize that part of what you've done is really a logically-distinct change and should go into its own commit?Sorry, I don't think anyone avoids things like these... and those are situations Git provides much better tools for dealing with than SVN, and covers a lot of what the flowchart is about.
-
I've had the extreme benefit of doing SVN in a small scale way; small teams of less than 5 people. Tends to mean a lack of headaches in general.
Have I forgotten files? Sure. I have learned from this and have taken to habitually marking them as added as soon as I create them. TortoiseSVN is good in that respect since you can also review the state of what you're committing before you press the button.
Partial fix? Sure. That's what communication is for.
Started working on something and watched it go out of scope? Rarely. I tend to focus on functionality in chunks specifically to limit that sort of problem so each commit is logically consistent and makes sense to be a distinct commit. I have no problem with one line commits if that's the appropriate thing to do.
I didn't say it had never happened to me, because clearly it has. My point, which I didn't spell out because that would be a barrier to brevity is that I don't get into those situations now because we have a workflow that works for us to avoid those sorts of shenanigans.
As compared to Git where I feel like I run into headaches every time I press the button to fire off changes.
-
I didn't say it had never happened to me, because clearly it has. My point, which I didn't spell out because that would be a barrier to brevity is that I don't get into those situations now because we have a workflow that works for us to avoid those sorts of shenanigans.
As compared to Git where I feel like I run into headaches every time I press the button to fire off changes.
Ok, but don't you think if you spent all those years gaining experience with git, you would now have the same sorts of practices and workflows for git instead of svn?
-
Probably... but on the other hand, Git feels so fragile that I fear I'm going to break the repo every damn time I try to do anything, something I never had with SVN.
It actively puts me off trying to get to know it.
-
Partial fix? Sure. That's what communication is for.
All the communication in the world doesn't help you (unless you have a much better memory than I do) six months down the line when you're trying to understand what you did six months prior, or when someone is trying to bisect through a broken commit.Started working on something and watched it go out of scope? Rarely. I tend to focus on functionality in chunks specifically to limit that sort of problem so each commit is logically consistent and makes sense to be a distinct commit. I have no problem with one line commits if that's the appropriate thing to do.
I have no problems with that either. Because I'm not talking about VCS-handling now, not really -- I'm talking about coding. And at least I often can't forsee exactly what I'll need to do to get something working. So I'll begin working, discover "oh, this API that I thought was there isn't, so I need to make it" and want that to become a distinct commit. But because I'll have a partial solution to the original problem started, now I have to figure out what to do with that partial solution. Sometimes it's even worse, and I won't realize I have two distinct logical changes until after both changes are sitting in my sandbox.And at least IMO, Git gives you much better tools for handling this situation. (In fact, I've even written a script to provide some of this capability in SVN. Use at your own risk, and I suggest NOT using it if you have any newly added files. It will probably break.)
Git feels so fragile that I fear I'm going to break the repo every damn time I try to do anything
I think it's the reverse... I feel like I have to step much more gingerly around Subversion working copies (which is what we use at work). In particular, takesvn up... that is a destructive operation if you have local changes. If yousvn up, decide you don't want to deal with the conflicts, and want to go back to where you were before that command, you can't. And you can't commit without updating. So the only thing to do is dosvn diff, save those changes somewhere, update, and if you're happy with the result, delete your patch file. (svn up --dry-runwould help a bit, but it by no means solves the problem.)By contrast, you almost have to try (or suffer a hard drive failure for things not pushed) to lose data that's been committed to Git. You can recover data from it that you've deleted all references to.
-
Yes, but I deliberately make efforts not to leave the repo broken. Ideally I try to always leave whatever I'm doing at a 'never broken' stage.
As for the chunking of commits, I tend to be one of these people who obsesses over the design phase somewhat specifically so I don't run into that kind of issue further down the line. Crazy levels of overthinking.
I dunno, I'm only going on my experience which is clearly different to yours. Mine has been fortunate that I've rarely encountered broken repos or anything like that and that the people I'm working with are sufficiently able to communicate what's going on that in general we just never really got into those kinds of problems anyway.
But I have the perpetual feeling of Doing It Wrong™ whenever I touch Git.
-
ut I have the perpetual feeling of Doing It Wrong™ whenever I touch Git.
I have that problem with both git and SVN. I'm working hard to be multilingual by using git at home and SVN at work :)
-
So you've never committed while forgetting to svn add something required?
The key is to use a RCS that your IDE understands, which guarantees this problem can't happen.
Of course one of the things I'm using SVN for is Skyrim mods, in which case it's a shitload of loose files all fucking over the place, and I have to manually add so I don't end up adding 15 terabytes of video game textures in addition to my 15k mod file, but hey. All software is shit.
EDIT: I guess nothing's stopping me from making a fake-o VS solution to store the Skyrim work, except I didn't think of it until now.
-
svn:ignore
.gitignore
etc
-
svn:ignore.gitignoreetc
... yeah I don't think you get how Skyrim modding works. Maintaining the .ignore file would be harder than just selectively adding files. Remember, I only want to check in my mods and adjustments to other people's mods. But my mods are in the same folders as 50 other people's mods, a selection of mods that changes on a weekly basis.
-
Yes, but I deliberately make efforts not to leave the repo broken. Ideally I try to always leave whatever I'm doing at a 'never broken' stage.
I was going to say something else before and forgot, but this reminded me of it. I think the following is a good summary of my feelings on the topic: the more you consider the repository itself (and not just the head revision(s)) as being an artifact of your development and the more effort/time you're willing to put into making the repository itself nice, the more Git provides tools that SVN can only do with a great deal more manual work.For example, take your statement: you try not to "leave the repo broken." But -- overstating things dramatically -- from one point of view, a SVN repository once broken is always broken. Once you make a commit that breaks something or doesn't make sense or whatever, that commit will always be there in the repository (modulo some very very deep hacking with
svnadmin dump/load). You can't fix the repository by making more commits that fix things, you can only fix the head revision.To a large extent this is just a fact of development and Git suffers from it as well, but at least for branches that haven't been made "public" (for some definition of that) yet, you still have the ability to fix things to improve the repository itself. You can decide that commit #10 and #20 are really quite related (e.g. you introduced a function in #10 then decided it would be better with a different name and renamed it in #20), so put them next to each other, or even combine them if that would make for a more understandable history. Or you could decide that some commit should be split up, and do that post-facto. Or instead of having a commit that does something wrong and another that backs it out, you can just dump both and simplify the history.
So a very natural workflow for Git when you want to work on a new feature for a few days is to make little commits as you go so that you have good checkpoints of "X works", "now Y works", "now Z works". Then, after things work, you can go back and make the history better.
(And in an attempt to preempt an argument: some people say that you shouldn't "rewrite history" like this. And there are certainly cases where you shouldn't; if something is public, it's almost certain that you shouldn't because the complications of doing so will outweigh the benefits of a cleaner history. But for the sort of thing I'm talking about above, I think it is very defensible. My position is that you're already rewriting history when you make the commits you do. You don't commit the version of the file where you typo'd
fopenintofpoenjust to show how you arrived at your final solution, nor do you commit every single version that successfully builds. Because doing that would make your repo history crap. Rebasing stuff to get a nice history before pushing isn't fundamentally different from being careful about what you commit in the first place.)he key is to use a RCS that your IDE understands, which guarantees this problem can't happen.
Not everyone has the benefit of working with an IDE.For instance, my working environment is that I do 99% of my development over SSH on a box several states away. It's too remote to run a GUI on the remote machine and remote desktop to it and have a system that is even close to not-laggy enough. I get the impression that Eclipse with a plugin called RSE might be able to support this mode of operation, but I haven't explored it much. Anyway, I don't think it would help much with the missed-add problem.
-
svn co https://github.com/discourse/discourseTry it.
-
Not everyone has the benefit of working with an IDE.
Sure they do, unless they're working with a really obscure-ass language. Really obscure-ass.
For instance, my working environment is that I do 99% of my development over SSH on a box several states away.
So... don't do that? Then you can use and benefit from an IDE.
"Some people can't use an IDE because they do intensely stupid things like remote control a computer over a 14.4 kbps modem!"
"The answer there is to stop doing the intensely stupid thing."
"Oh right, I didn't think of that."
Anyway, I don't think it would help much with the missed-add problem.
I don't think even Eclipse is that awful. Maybe I'm wrong, I don't use it because I don't enjoy using terribly broken shit.
-
That's kind of my problem with this: you're assuming that the codebases I work on are built the way you think they're built.
We have a pretty iterative design on things, meaning that for us, SVN actually works pretty well without mass branching going on. I'm not saying that it's a perfect tool - but I do find it disconcerting how hard you're trying to tell me I'm doing it wrong when for what I do, it's much less of a problem to use SVN than it is to use Git.
Interestingly, this is the same problem I have with people trying to extol the virtues of Linux on me. I don't give a shit about how wonderful it might be once I go through the pain of relearning everything and making everything work again, I just want to get on with my day and do what I do. If I have to stop to think about how my tools work, something is drastically wrong.
I also suspect you think I didn't use Git. I used it for 6 months. Hated the entire experience, though it was made much less painful by way of SourceTree. But still fragile and felt like it would fall apart any minute.
-
Yes, but I deliberately make efforts not to leave the repo broken. Ideally I try to always leave whatever I'm doing at a 'never broken' stage.
This only works in a team of one. And it's not just "repo broken," but "repo conflicts with what I just did in my working copy."
-
Maintaining the .ignore file would be harder than just selectively adding files.
I'm not intimately familiar with the details of these files, but I know that hg at least allows you to use regular expressions, which is pretty powerful.
-
I also suspect you think I didn't use Git. I used it for 6 months. Hated the entire experience, though it was made much less painful by way of SourceTree. But still fragile and felt like it would fall apart any minute.
Not just you. The first 6-months of me using Git were "detached head" for literally no predictable reason whatsoever. Turned me off for good.
Maybe it's great if you read giant textbook and have an expert explain it and have like 20 weeks to play around with it before you have to actually use it to get a job done, but I was just plopped onto a project, "oh BTW we use Git for it", and that's it. And in that scenario, otherwise known as "the most common scenario for a tool like this", Git is a raging piece of shit.
-
You'd be surprised actually. A little thing called communication goes an extremely long way.
Great example: one of the projects I contributed to was a fork of SMF. Team of two. I made hundreds of commits. I had to manually deal with conflicts like less than a dozen times in 3 years. The other guy, similar amount. Communication and separation of duties.
The overall point is that speaking in generalities is great until you encounter someone like me that bucks the trend. I have no doubt my experience is atypical but the point is I have had it and it's worked out pretty good for the projects I've been part of over the years.
-
I don't think even Eclipse is that awful. Maybe I'm wrong, I don't use it because I don't enjoy using terribly broken shit.
I use Eclipse all the time. I actually have the reverse problem, where I don't want to add things, but it puts them in there. Fucking stop it already.
My cow-orkers, of course, routinely forget to add their shit. And, yes, they use Eclipse. They are just that dumb.
-
I'm not intimately familiar with the details of these files, but I know that hg at least allows you to use regular expressions, which is pretty powerful.
I'm not saying it would be impossible, or even difficult, it would just be fucking annoying as shit. You can't use file extensions, for example, because the mods I want in source control and the 47 mods I downloaded from Steam all are .esp files. You can't use file paths because, ok I liked that mod but I had to go in and fix their texture files by greyscaling them, and I want to store the 3 .dds files I edited but I certainly don't want to waste my limited repo space storing all of the *_msn.dds files or the *_s.dds files. So RegEx doesn't even help with a problem like this.
And even if I did have a working RegEx for this week's set of mods, next time I install a new mod oops, time to go back and redo it. And that happens pretty damned often.
For some reason, putting a slash in front of those particular asterisks isn't escaping them (natch, because that worked yesteray), so you'll have to cope with the random italics.
-
This sounds like an example of, what's the word...oh, yeah, intensely stupid shit.
-
This sounds like an example of, what's the word...oh, yeah, intensely stupid shit.
I agree, but unfortunately I can't go back and magically engineer the Creation Engine to support mods in a cleaner fashion. The files have to be at specific places in the folder tree, there's no way to just make a /mymods folder and be done with it.
-
FLAGGED FOR WHOOSH <badge>
-
SVN actually works pretty well without mass branching going on. I'm not saying that it's a perfect tool - but I do find it disconcerting how hard you're trying to tell me I'm doing it wrong when for what I do, it's much less of a problem to use SVN than it is to use Git.
Sorry if I came off that way; my goal was much more to say what I like about Git and to some extent why it has the things it has. Edit: and why I suspect I think that by my standards you would be ending up in "the green box" more than you do. That's not necessarily a bad thing; even I am not convinced that cleaning up the VCS history is worth the time it sometimes takes, even as I'm doing it. And lowing my "green box" standards means that I wouldn't have to do it as much. (And higher/lower isn't meant to be a value judgement here, just a reflection of more or less strict.)
-
I see a callback but not a whoosh. So maybe it's a double-whoosh, I don't get the whoosh even when told it's a whoosh.
Chrome's dictionary doesn't include the word "renderer", but it does include the barely-word "whoosh". WTF.
-
I see a callback but not a whoosh. So maybe it's a double-whoosh, I don't get the whoosh even when told it's a whoosh.
Fuck. Explaining a joke to blakeyrat. Is there anything lower? An adult modding video games (other than as part of his job) is intensely stupid.
-
Why is it stupid?
-
Why isn't it?
-
Why isn't it?
That's not a whoosh, that's just a joke so awful I didn't get that it was a joke.
-
That's not a whoosh, that's just a joke so awful I didn't get that it was a joke.
This isn't surprising, because you do intensely stupid things.
-
For instance, my working environment is that I do 99% of my development over SSH on a box several states away. It's too remote to run a GUI on the remote machine and remote desktop to it and have a system that is even close to not-laggy enough. I get the impression that Eclipse with a plugin called RSE might be able to support this mode of operation, but I haven't explored it much. Anyway, I don't think it would help much with the missed-add problem.
I had to do that once. I cloned the project locally, wrote a bash script to rsync the folder over ssh and made a grunt task to call that script every time there was a change. Presto.
There's no way I'm coding over SSH using some crappy CLI editor. That's just insane.
-
I agree, but unfortunately I can't go back and magically engineer the Creation Engine to support mods in a cleaner fashion. The files have to be at specific places in the folder tree, there's no way to just make a /mymods folder and be done with it.
I'd tend to use an 'external sources' folder, a 'my stuff' folder, and a shell script to merge the two. But I almost exclusively work on linux, and I wouldn't have a clue how to set that up on windows.
-
So every time before you test your code you have to run the merge script? That sounds like the most annoying workflow imaginable.
-
OK, so if SVN is outmoded and Git is crap, how do people feel about the alternatives (Mercurial, Bazaar, etc)? I haven't experienced any of them, and am curious about opinions.
Preferably serious ones, for once.
Not that I'm going to hold my breath waiting for that.
Filed Under: Hope springs eternal.
-
Lemme explain "detached head" for you:
Some gigantic shitlord was working on the project with you. You and he were doing your own things, and you pushed your commits upstream, as you should have. Then he tried to push his commits, and got an error message that went something like
can't fast-forward upstream. This means that he was trying to push commits that didn't include your work. But rather than accepting this, pulling your work and merging it in with his, the gigantic shitlord decided to force through his push anyway, bypassing two warning screens which explicitly said "this will wreck everyone else's repo, only do this to fix [these specific problems, none of which is "I don't wanna merge"], are you ABSOLUTELY SURE?"Thus, as a result of the gigantic shitlord's actions, you weren't working on a branch anymore. It's gigantic shitlord who's to blame, not Git.
That said, Git is very terrible if you're not using Visual Studio's built-in support or Eclipse's built-in support or at the very least some sort of GUI. And it's sad that the documentation on how to escape this situation is lackluster at best.
-
Lemme explain "detached head" for you:
Nope. Was a bug in Git.
Thus, as a result of the gigantic shitlord's actions, you weren't working on a branch anymore. It's gigantic shitlord who's to blame, not Git.
Nope. Was the fault of a bug in Git.
Thank you for the wrong explanation that is wrong and makes you an idiot, and while what you describe might cause "detached head", that is not what was happening to me. My "detached head" errors were a result of Git having a hissyfit about Windows' file locking. Because apparently they "ported" Git to Windows without knowing a single thing about how Windows actually works.
Oh and BTW, the fact that the thing you describe is even fucking possible is a bug. I don't care how gigantic this shitlord is, that's a bug in Git.
-
In my experience, 50% of developers are gigantic shitlords. There are a ton of people that wish for the days of Visual Source Safe, because they think it's better for them to lock and sit on half the code and make everyone else beg for them to release a file every once in a while than to accept that multiple developers means that every once in a while, two of them will do things that have to be woven together by someone who actually understands the structure of the file that was modified.
When these people meet non-locking VCSs (distributed or not), they just overwrite everyone else's work and blame them for not including him on every meeting and discussion that ever takes place.
-
Oh and BTW, the fact that the thing you describe is even fucking possible is a bug. I don't care how gigantic this shitlord is, that's a bug in Git.
A rough equivalent of this happens to me all the time in TFS. It doesn't affect the whole branch like "detached head" does, but every file he touches becomes a merge nightmare.
-
My "detached head" errors were a result of Git having a hissyfit about Windows' file locking.
I dunno...your description here:
GitHub is fucking broken fucking again
Here's the next part of my email chain with the GitHub guy: @GitHub support guy said:I'm going to do my best to address your concerns. 1)The gibberish in your source code files are merge conflict markers that are created to help you resolve the conflicts ...
...sounds more like @TwelveBaud's shitlord scenario than windows file locking. Except you're probably the shitlord.
-
And the solution/alternative is? The only ways I can see preventing it are either a) force-locking, which makes distributed development effectively impossible, or b) forced merging, which would prevent that behavior but open up a large number of other flaws.
I suspect that, as an opponent of OSS and distributed development in any form, you'll go with option a), despite the fact that it would hobble any development group larger than two, distributed or not. Even in a small, fixed, and physically localized development group, forced locking is the bane of group productivity. There's a reason even Microsoft don't use VSS themselves, though they keep quiet on just how they actually handle source control.
-
OK, so if SVN is outmoded and Git is crap, how do people feel about the alternatives (Mercurial, Bazaar, etc)? I haven't experienced any of them, and am curious about opinions.
Preferably serious ones, for once.
Not that I'm going to hold my breath waiting for that.
Filed Under: Hope springs eternal.
I briefly looked into Mercurial on the account of some people I respect swearing on it.
It's like git. The biggest difference: git uses one folder and manipulates files to match the current branch. Mercurial uses separate folders for each branch. I prefer the git way, so I stayed.
