Git troubleshooting flowchart
-
I'm using the GitHub software on Windows, starting about a year ago maybe? More regularly in the past 6 months or so. And it's been a LOT better than Blakey describes, so I suspect it's matured quite a bit since he was using git on Windows, probably because it was a huge shitfest when he was using it. I do forget to sync sometimes, but the graphical interface hides a lot of the weirdness of git from me so I can use whatever workflow works for me.
I use TortoiseSVN at work, and I've had a lot more problems with that, mostly from forgetting to svn update before I svn commit. The Github graphical software makes it clear to me how many revisions I'm behind at all times, so I remember to sync more often. That's probably just me, though, I tend to program while groggy or in pain a lot, so I forget simple things. I do know that when I fuck up with SVN, I have to go running to one of my more experienced coworkers and beg them to fix the repo >.>
Speaking of, I wonder if my experienced coworker is free, I fucked up my repo again...
-
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.
But if you do manage to completely destroy your repo, well, you broke your repo, you don't break the repo. You can just clone a new one from any other copy.
You can even have multiple repos on the same computer. If you're about to get in the "danger zone", just copy the whole folder someplace else, try your black magic, and if it didn't work, throw it away.
-
...sounds more like @TwelveBaud's shitlord scenario than windows file locking. Except you're probably the shitlord.
If it is, then Git is so horrible it can actually summon a shitlord from beyond the grave to fuck up repos that nominally only have one user.
Although I guess it is possible that developer in Portland was fucking with the repo, it seems unlikely though.
-
And the solution/alternative is?
I'm not saying there a solution, I'm saying it's a bug.
-
Blakey is more of a rant guy than a solution guy. :-)
-
There's a reason even Microsoft don't use VSS themselves, though they keep quiet on just how they actually handle source control.
It might have something to do with VSS being deprecated like A FUCKING DECADE AGO, why the holy shit in hell do people keep bringing up VSS in source control treads as if it were relevant at all? Christ.
Hey let's now spend a bunch of time talking about Windows 3.1 because that's about as relevant to the issue as VSS is at this point!
-
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.
The Git way can pretty much be done in Mercurial at this point, using Bookmarks. I haven't put this theory to the test, but I suspect that Mercurial with a few (built-in) extensions enabled for things like rebasing would give you something that I would be very happy with. I'd say the biggest difference at this point is that Mercurial wasn't designed by someone who thinks that CVS is worse than no version control and that Subversion is thus the dumbest project ever, and thus Hg doesn't have several commands that appear to be explicitly designed to make SVN users angry.
-
I'm using the GitHub software on Windows, starting about a year ago maybe? More regularly in the past 6 months or so. And it's been a LOT better than Blakey describes, so I suspect it's matured quite a bit since he was using git on Windows, probably because it was a huge shitfest when he was using it. I do forget to sync sometimes, but the graphical interface hides a lot of the weirdness of git from me so I can use whatever workflow works for me.
Does it do conflict resolution now?
My biggest issue was that HUGE missing feature, and the fact that they slapped a 1.0 version number on a source control client that couldn't do conflict resolution.
-
The biggest difference: git uses one folder and manipulates files to match the current branch. Mercurial uses separate folders for each branch
Huh? I've used the same directory with multiple branches. What mercurial doesn't do is save uncommitted changes when you switch branches, which I think git does. Is that what you mean? I find that when I need to work on different branches at once, I like having them separate. It's easier to keep everything straight in my head.
-
OK, valid point. The problem is, in public at least, Microsoft never offered any replacement, as far as I am aware, so whenever VCS does come up in reference to Microsoft, VSS is the only thing anyone has to point to. The implication is that MS have rejected VCS outright after a single flawed attempt at it.
Does anyone here know what Microsoft uses for source control internally? Or Oracle, for that matter, since they are (AFAICT) oddly silent on the issue?
-
Blakey is more of a rant guy than a solution guy.
That's not the point.
It's a bug whether or not a solution exists, or is even possible. So if I say, "that's a bug," replying, "it's not a bug because there's no solution to it!" is stupid and misses the point entirely.
People grow old and die. That sucks. It's a bug. Is there a solution? No. But that doesn't make it suck any less, and that doesn't make it any less of a bug.
-
If it is, then Git is so horrible it can actually summon a shitlord from beyond the grave to fuck up repos that nominally only have one user.
I dunno...I just looked back at that thread, and the linked post seemed like the most descriptive thing. Quick searches didn't turn up anything about Windows locking files.
-
Does it do conflict resolution now?
I googled, looks like no. Well, that's absolute shit :( I haven't run into conflicts yet, so I just assumed it had a nifty popup or something. Ick.
-
I have very superficial understanding of hg, but that's what tutorials said when I gave it a brief shot. Sort of, unlike git, you're supposed to separate your branches into different folders.
I prefer single directory workflow, it's easier to set up all the tools around this folder (grunt, editors, web server etc). I do have a few local copies of the repo, so I can checkout multiple branches at once, but they do not map exactly to branches (think folder names like "main", "stable", "experiment").
-
That's not the point.
It's a bug whether or not a solution exists, or is even possible. So if I say, "that's a bug," replying, "it's not a bug because there's no solution to it!" is stupid and misses the point entirely.
People grow old and die. That sucks. It's a bug. Is there a solution? No. But that doesn't make it suck any less, and that doesn't make it any less of a bug.
You're not supposed to be reasonable when people make digs at you. Now I feel like I kicked a dog... :-)
-
I have very superficial understanding of hg, but that's what tutorials said when I gave it a brief shot. Sort of, unlike git, you're supposed to separate your branches into different folders.
I probably have an even more superficial understanding of git, but I would definitely check out branches into different folders when I need to be able to be working on them simultaneously.
-
OK, valid point. The problem is, in public at least, Microsoft never offered any replacement, as far as I am aware,
Do you even work in IT? What the fuck. How is it possible someone who works in IT, who is aware of VSS, who presumably isn't DEAD, can not be aware of TFS?
No, this isn't a Microsoft problem, this is a problem of your own awareness. You are apparently not aware of jack shit.
so whenever VCS does come up in reference to Microsoft, VSS is the only thing anyone has to point to.
Right. Not, for example, TFS, which has been their supported source control product since like 2005.
Does anyone here know what Microsoft uses for source control internally?
Gee, I dunno. Maybe... TFS? You raging dimwit?
I dunno...I just looked back at that thread, and the linked post seemed like the most descriptive thing. Quick searches didn't turn up anything about Windows locking files.
I actually got that from an email exchange with a developer who worked for GitHub for Windows. They were probably getting fed up with me sending them a support email basically three times a week, whenever I had "detached head" and had to re-pull the repo and start over. (Yes, yes, I'm sure there's another way to fix it, I don't give a shit.)
BTW, they never proposed it was due to sabotage from another person with access to the repo.
Anyway, I'll hand GitHub this: at least their support was helpful. Then again, our company paid them for the repos.
-
I actually got that from an email exchange with a developer who worked for GitHub for Windows
I actually found that thread when looking to see if it had added a conflict resolution tool. http://forums.thedailywtf.com/forums/t/26960.aspx if you want it. I think this is the bit from the email you're talking about?
- The 'detached HEAD' error happens when GitHub for Windows interrupts a sync due to merge conflicts between the local and remote repository. Fixing this involves opening the shell, running 'git status' to see the specific files with conflicts, fixing those conflicts, and then running a 'git rebase --continue' to finish off what GitHub for Windows was initially trying to do. I agree that this is cumbersome to new Git users, and we're working on a better way to handle merge conflicts directly in the GUI so that users don't have to email support to figure out what on earth is going on.
-
Yeah, git itself will only go so far as tell you where conflicts are (
git diff) because, well, if it could solve them, it would have already. Git for Windows is not an IDE, either, so you might want to install kdiff3 or a similar tool in advance.
-
TortoiseSVN isn't an IDE either. It does, however, have a feature where you can tell it to open the conflicting changes in BeyondCompare (or its own diff program if you don't have BeyondCompare) and you can resolve the issue without dropping to a command line. That's what I'm looking for, some way to stay out of the shell.
-
They might have added that little paragraph due to my bitching haha. Or maybe it's an unrelated "detached head" bug, I dunno.
Point is, back when I worked at a company that was paying GitHub and before MS's client was available, one of their support people blamed a bug in Git that didn't play nicely with Windows' file locking. I don't dig into it any more than that, and then Microsoft basically swooped-in and made a non-shitty Git client. (Well, it's still shitty, but it's way LESS shitty.)
-
The paragraph I quoted is from a post you made in the old forums where you quoted from an email from the GitHub dev, so I assume that was your bug. Unless the guy misunderstood your problem, which is 100% possible, I skimmed the thread looking for something that looked like a bug explanation.
-
The command line program
gitdoes the same, too; just tell it what to use formergetool. Hey, maybe Github for Windows will launch that tool for you if you configure it? It may be worth a shot.The one-time incantation is:
git config --global merge.tool "whatever"
-
That's what I'm complaining about: Github for Windows doesn't seem to have a way to launch any tool. It just flags "hey, there's a conflict, go to the git shell to fix it manually plz."
-
BTW, they never proposed it was due to sabotage from another person with access to the repo.
Here's where the magic happens:
The 'detached HEAD' error happens when GitHub for Windows interrupts a sync due to merge conflicts between the local and remote repository
...and the fact that you still haven't comprehended that sentence.
-
BTW, this is the most baffling reason that I see over and over as to why git is better than SVN. I regularly have people tell me "git is better at merging". To which I can only respond: SVN doesn't do non-trivial merge conflict resolution - it just hands the base version, your changes, and the repo changes to a merge tool and tells that tool to do a three-way merge. How can git be better at something that SVN doesn't do? Also, if git has a built-in three way merge, I'm sure it's inferior to BeyondCompare and probably kdiff too.
-
I'm suggesting that if you configure the underlying git installation to use your tool for merge tool, Github for Windows might launch it for you. I don't have Github for Windows installed right now so I can't check.
See this page for example.
-
The "git is better at merging" thing seems to be, from what I understand, the assertion that git can automerge more things than SVN can. Remember that both tools will do their best to automerge things and only give you a conflict when they can't figure it out. SVN can be really stupid sometimes about what it can't figure out. Supposedly, Git is smarter.
-
Do you even work in IT? What the fuck. How is it possible someone who works in IT, who is aware of VSS, who presumably isn't DEAD, can not be aware of TFS?
Simple: I've never heard of it because I don't work with it, and don't know anyone who does. Of the two .NET shops I've worked in in the past ten years, one used SVN, and the other stubbornly refused to use any VCS no matter how I plead with them over it. In any case, I haven't been developing with any Microsoft development tools in any of the jobs I've been doing since 2010, including the current one, not because I avoid them (though I do) but because I just haven't been working in them. TFS simply wasn't on my radar. I doubt anyone I've worked with has heard of it. I imagine only diehard MS developers have, and even then most of those don't seem to use it.
-
BTW, this is the most baffling reason that I see over and over as to why git is better than SVN. I regularly have people tell me "git is better at merging".
I think svn has gotten better at the mechanics of merging. The problem is the paradigm is fucked up. With svn, you have to merge before you can commit if someone has committed since you last updated.
With a sane tool, you can finish your work and commit your changes. Then you can merge that with stuff that other people have done.
I didn't really understand this until I started using a DVCS, and it seems that other people don't either, sometimes even after they've been using a DVCS for a while.
-
Yeah, the real advantage seems to be the built-in branching capability in that every local copy is basically like a branch in SVN. Branching should be a lot easier than it is in SVN, and that's what (in theory) git is trying to solve. At my work we're torn between wanting to branch more and being afraid of branches because things can go so terribly wrong.
-
With svn, you have to merge before you can commit if someone has committed since you last updated.
TFS works like this too. I see no problem with the paradigm of "Whoa, you better verify your changes before committing them, someone else messed with these files". Otherwise, you get a blind merge and no one verifies that the merged code actually works. TFS will do this if you don't have a working copy of the merge target and there are no conflicts. But, at least it yells at you and stops if there are conflicts.
-
For those who are interested in experimenting with branches but don't want to actually deal with elaborate setups to simulate them in a real environment, this "game" is not terrible.
Yes, git doesn't actually give you such a graphic representation to begin with... or does it? ;)
git log --all --graph --decorate --oneline --color
-
That's what I'm complaining about: Github for Windows doesn't seem to have a way to launch any tool. It just flags "hey, there's a conflict, go to the git shell to fix it manually plz."
Yeah, same as when I used it back in the day. They basically implemented every part except the most important bit. Idiots.
Incidentally, GitHub is big into open source software. COINCIDENCE!??! ... no. All open source developers are shit.
-
I have very superficial understanding of hg, but that's what tutorials said when I gave it a brief shot. Sort of, unlike git, you're supposed to separate your branches into different folders.
While it'd be somewhat reasonable to say that's somewhat of a "Merucurialish" way of working, it's far from the only. Mercurial has two methods of single-directory branching, including one ("Bookmarks") that are very git-like. Whether you view this as Hg supporting some non-Mercurialish ways of working or expanding the definition of Mercurialish is up to you.Rebasing is another thing on this line. Rebasing isn't part of the "traditional" Mercurial workflow, which prefers merging. But nevertheless, Hg has supported rebasing for a long time quite competently.
Gee, I dunno. Maybe... TFS? You raging dimwit?
Yes and no. Depends on the project. MS also uses a modified version of Perforce they haven't released publicly. (http://blogs.msdn.com/b/eric/archive/2008/04/12/devdiv-source-control.aspx)The "git is better at merging" thing seems to be, from what I understand, the assertion that git can automerge more things than SVN can.
It was borne out of the increasingly-irrelevant fact that Subversion used to not do merge tracking, so whenever you wanted to do a merge, you had to manually specify a revision range. Subversion 1.5 started tracking mergeinfo, which supposedly makes this less of a problem. It's reintegrating a branch, not the three-way merge itself, that claim was borne out of.
-
TFS works like this too. I see no problem with the paradigm of "Whoa, you better verify your changes before committing them, someone else messed with these files". Otherwise, you get a blind merge and no one verifies that the merged code actually works.
Honestly, it goes beyond "messed with these files." If someone changed something that your code (@blakeyrat TRIGGER WARNING: word that can be used in different ways ahead) depends on, your stuff may no longer work as expected. To me, it kind of feels like getting the rug pulled out from under me when svn does this to me. Granted, most of the time it's not a problem, but sometimes it's a real bitch.
-
Simple: I've never heard of it because I don't work with it, and don't know anyone who does.
Too bad it's not possible to somehow learn about things, even if you have no personal experience with them.
Look. If you didn't know that VSS was deprecated a decade ago, and you didn't know that TFS replaced it at that point, and you aren't aware of the source control package used by the largest software company in the world and thousands of smaller ones, you are a bad developer.
If I am a client, and I come to you for solutions, can you name anything more recent than 2005? Or are you just writing antique software because at some point your brain just turned off and you stopped learning new things entirely?
TFS simply wasn't on my radar. I doubt anyone I've worked with has heard of it.
I bet your co-workers would love to hear how you're projecting your ignorance and incompetence onto them as a deflection in an Internet debate.
I imagine only diehard MS developers have, and even then most of those don't seem to use it.
Right; now you're not even ignorant, you're average. In fact let's go a step further: "only FREAKS have heard of TFS!" There, now you're in the non-FREAK group. Hey we can extend this: "only child molesters have heard of TFS!" Look at that, being ignorant is now a moral imperative! Awesome.
Seriously, though, part of being in IT is learning. If you've stopped learning and evolving, you're dead. Go dig a ditch for a living.
-
Yes and no. Depends on the project. MS also uses a modified version of Perforce they haven't released publicly. (http://blogs.msdn.com/b/eric/archive/2008/04/12/devdiv-source-control.aspx)
Based on a 2008 source?
I dunno. Maybe they are still using that, I doubt it though. They are probably also using Git internally, now that TFS supports it. Microsoft has thousands of projects, so blanket statements are usually wrong in that type of environment.
-
Too bad it's not possible to somehow learn about things, even if you have no personal experience with them.
QFT
<it's funny because it's true>
-
I've never found branching in SVN to be difficult since they added merge tracking in 1.5 (in 2008). At my previous job, we did all work in feature branches and used SVN. Source control never got in the way of getting things done. BTW, SVNs externals are awesome and I really miss them now that I primarily use TFS. I hate forcing a developer to manually build a working copy for projects that include source that is shared across projects.
-
We get merge conflicts.... not very often, but when we get them, they're nasty as heck. Tree conflicts are the worst.
-
To me, it kind of feels like getting the rug pulled out from under me when svn does this to me. Granted, most of the time it's not a problem, but sometimes it's a real bitch.
But, those things happened. Someone's got to be responsible for cleaning up the resulting mess. First one to commit can't because he doesn't have the whole story, so the logical choice is to make the second person fix it. That's exactly what is happening when you feel like the rug is pulled out from under you. If git doesn't make you feel that way, then who gets the rug pulled out from under them?
-
Unrelated: in the linked cs thread, blakey has a nice rundown of how Windows environment works. Some stuff I didn't know. +1
-
...the hell? Between my posting that earlier link and your posting this one, my work filter has decided to block the old forums. WTF.
-
...the hell? Between my posting that earlier link and your posting this one, my work filter has decided to block the old forums. WTF.
Atwood's everywhere!!!
-
They are on to you! RUN!
-
Based on a 2008 source?
I don't. You can cut the date down by half to 2011 (secondary souce, original source on wayback machine), and I can't find any more recent sources talking about what they're using, Source Depot or TFS.I dunno. Maybe they are still using that, I doubt it though.
Microsoft has thousands of projects, so blanket statements are usually wrong in that type of environment.
You mean blanket statements like "the source control package used by the largest software company in the world"? :-)
-
We get merge conflicts.... not very often, but when we get them, they're nasty as heck. Tree conflicts are the worst.
A tree conflict results from two people adding a file with the same name independently. They're the worst because there are two ideas about how to implement something.If merge conflicts are nasty, then your actual conflicting changes are nasty. No one can make is easy on you if two different people change 80% of a 500 line source file and both commit it.
-
You mean blanket statements like "the source control package used by the largest software company in the world"?
"Do I contradict myself? Very well, then I contradict myself, I am large, I contain multitudes."
- Walt Whitman
-
A tree conflict results from two people adding a file with the same name independently.
We never, ever have that problem. Usually it's something like, someone deleted a file, committed the delete, but forgot to merge the delete commit, and merged in further commits. Or someone deleted a file, committed, undeleted it, committed that too, and then tried to merge up to demo without merging either commit because in their mind, it was reverted anyway, so who cares?
Or someone did that a year ago, somehow forced the merge through, and the next guy just changed one line.
Ooh, or someone deleted a file in their branch, and someone in another branch made edits, and the delete guy went to shared demo first, and now the edit guy wants to go in and there's no file there but he's made changes to it...
