Git troubleshooting flowchart
-
What source code control is used for Windows is relevant to most of us. I don't work on a project with millions of lines of source code and hundreds of developers, so I probably shouldn't use whatever Microsoft uses for Windows.
-
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.
From my experience, moving and renaming of files are one of the things that Git can handle much better than SVN. SVN seems to have been implemented with the tacit assumption that once the source tree was laid-out, none of the folders would ever be moved or renamed. Which is not even close to how I work.
I'm still getting up-to-date on the newer TFS version, so I'm not sure how well it handles those scenarios yet. I don't think it could possibly be worse at it than SVN though.
-
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...
So, you guys cant figure out "Merge a range of revisions" - which tells you which changes have and haven't been merged in and it's SubVersions fault? If you use TortoiseSVN, it will even let you select everything and it will only merge in the ones that haven't been done yet.I get Linus's point that metadata shouldn't be in the working copy itself. That was an engineering tradeoff made by SVN that has more minuses than pluses. But much of the rest of the SVN hate seems manufactured.
-
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?
Yes, and I'm happy to fix them, but just let me do my thing first and get that committed and recorded. Shitting all over my changes is just goddamned rude and a barrier to productivity. I'm fine with fixing it, but my version control software shouldn't make it harder like svn does.
To be clear: I don't always use DVCS, but when I do, I use Mercurial.
-
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.Actually, I've asked about it, and none of them have. Since most of them have only been in the industry since around 2008 or later, I doubt that they are hopeless mired in the past.
In any case, I confess: I haven't kept up with every tool on the market. Call it human nature, but with as vast an industry as this, I doubt many have even tried. It is a failing of mine, given the apparent ubiquity of this tool that no one I know has ever heard of, and I apologize if I have thus offended you.
-
-
From my experience, moving and renaming of files are one of the things that Git can handle much better than SVN. SVN seems to have been implemented with the tacit assumption that once the source tree was laid-out, none of the folders would ever be moved or renamed. Which is not even close to how I work.
Agreed. For most of my work, source files are named the same as the class that's in them, so renaming files is extraordinarily rare. However, since this covers C#, VB, Java, and a whole bunch of other languages, I would think that is covers the majority of developer use cases.
-
I am supposedly a NET programmer and I only learned about SharePoint a year ago, when our company flirted with going that way for a week or two. I never actually used it.
I don't think it's as widespread as blakey thinks. At least outside of US it isn't.
-
Agreed. For most of my work, source files are named the same as the class that's in them, so renaming files is extraordinarily rare. However, since this covers C#, VB, Java, and a whole bunch of other languages, I would think that is covers the majority of developer use cases.
I don't do a lot of renaming, but I refactor my java packages as time goes on, so stuff definitely moves around.
-
Yes, and I'm happy to fix them, but just let me do my thing first and get that committed and recorded. Shitting all over my changes is just goddamned rude and a barrier to productivity. I'm fine with fixing it, but my version control software shouldn't make it harder like svn does.
SVN allows that use case. Just make a branch and commit to that branch. You can do it without affecting the changes in your working copy. If this happens to you a lot, go to a "branch per developer" model and you can experience a workflow very similar to a DVCS, but you can apply permission and make sure contractors are actually doing their working and committing their incremental changes somewhere safe instead of the local repo on their C drive.
-
"Merge a range of revisions"
When we're selecting a dozen or two revisions that represent one project in dev out of maybe a hundred or two commits that happened in dev during that time period, it's easy to miss one checkbox. We do a LOT of commits, working on a LOT of simultaneous projects and small enhancements.
-
SVN allows that use case. Just make a branch and commit to that branch.
That's true. PITA, but true.
-
What source code control is used for Windows is relevant to most of us. I don't work on a project with millions of lines of source code and hundreds of developers, so I probably shouldn't use whatever Microsoft uses for Windows.
This. There are version control systems intended for suites with 9-digit LOC counts and build times exceeding 24 hours. You do not want to use them for your 50KLOC project. Trust me.
-
Might I recommend Atlassian's SourceTree to you? Unfortunately Atlassian is the same company that foisted fucking JIRA on the world, but SourceTree is quite good.
I wonder what @blakeyrat thinks about using a GUI that wraps itself around the command line too...
-
I wrote a big rant about how my company hates new tools, then I realized it's a Git tool, you meant for my home projects. I've yet to have a problem GitHub isn't good for in my home projects, but when I do, I'll look into SourceTree.
-
I did try the Shithub client but I found it was largely braindead. SourceTree made my 6 months of Git less intolerable, but only barely. I did like the ability to stage commits that were parts of files, though, that was the one thing I liked over SVN. Shame it came with so much other crap that I just didn't understand.
That reminds me, what does @blakeyrat think of JIRA?
-
The biggest source control issue I had with git has to do with using eclipse and unicode and for whatever reason, git deciding every line of every file had changed when I changed nothing. I hypothesized that it was an encoding change, but the most recent time eclipse warned me that it had to change a file's encoding because I used unicode characters, I didn't get any issues like this.
I made this commit just to shut it up: https://github.com/yamikuronue/Poker/commit/ee98f61e2a32da87ca2be9b307073d5931fdff7c
-
Line ending differences?
Also, that's a question for @blakeyrat, his preferred line ending. Is he a CRLF or LF kinda guy? (We pretend Mac use of CR only in the olden days doesn't happen any more,)
-
SharePoint at this point is kinda like a cult. Much like a cult those that aren't indoctrinated view it with suspicion, fear and loathing.
-
PITA
Really? I find it more convenient than having to manage interim commits from others while I'm developing...
-
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.
And then there are some that have enough experience to know that VSS supported concurrent checkouts, and worked at companies that didn't suck, and enabled that.
-
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.
Although I wholeheartedly agree with you, the company I work at used VSS until they started having applicants go "fuck this noise" and apply somewhere else. This was a year ago. Faced with the fact that it's probably time to switch somewhere else, they decided to go for Git. Our company is loosely structured into a .NET department and a PHP department, I'm part of the latter. We've been using Git, the .NET guys are still on VSS.
I know it's just an anecdote, but I do feel I need to pipe up here and say that there are jackasses out there who think VSS is awesome and don't want to use anything else, and some of those jackasses are lead developers at companies that employ a dozen people.
-
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.
You, as a developer, should be responsible for checking that the code actually works. If nobody's checking that, you who committed the code at the very least are at fault.
In Git, the philosophy is that you can do whatever you want, and then decide what to share by deciding which commits to push to the outside world. So you work, you commit but check your fucking work while you commit, and then if necessary, you merge stuff other people did and proceed to check your fucking merge before you push. In Git, a merge is just a commit with more than one parent, so if you push a merge, you should be responsible.
-
... you can apply permission and make sure contractors are actually doing their working and committing their incremental changes somewhere safe instead of the local repo on their C drive.
Situation my company encountered: they employed a developer who was very sloppy, in that he would push code to production without checking it, and not use VSS properly. As I've mentioned in another comment, we're switching to Git at the moment. One reason against switching from VSS, is the "bliss" of file locking and check-in, check-out mentality of having everything at a central hub so at least the boss knows what the guy is doing!
My argument against this was, well, Git won't be much different because the guy will just go from not checking in or checking out, to not committing and pushing, which of course is exactly what happened. They still had production sites that didn't match source control, they were still mile high in regressions and spaghetti code, and they discover that honestly, with VSS it was just the same except at least they could see which files he had checked out, but they discovered that unfortunately they had no magic mirror that looked into his workstation.
You see, he'd just do what I do when I need to work with VSS: flip the read-only bit, do some work, then do a project diff, and check in/out the changes you need to commit all at once. Except he'd skip the checking in/out part.
But in the end they solved the problem!
So what was the solution? What source control software trick saved the day? What productivity management tool did the trick? They canned the guy, that's what.
If your contractors can't be fucked to work with you, hire someone else and state in their contract that they are obligated to manage your code responsibly. This sort of thing should not be enforced by software, but by people.
-
SharePoint
SharePoint <> Team Foundation Server/Service
Don't confuse those they have nothing in common./There has to be some thing here to prevent those Boxes of touching each other in an unholy manner. An empty line is obviously not enough/
-
There you go. I have very faint understanding of this extended universe of Microsoft technologies. I just never got the chance to use any of it, so it all blends together.
-
it all blends together.
It does, even MS sometimes seems to be lost where one product stops and an other begins. The "Cloud" doesn't help either.
-
I have very faint understanding of this extended universe of Microsoft technologies.
What? How can you call yourself a developer without a fundamental and exacting knowledge of what the largest software company in the world does? Pitiful.
-
So @blakeyrat would say, anyway.
Never mind that I too have a fairly limited knowledge of MS technologies since I don't use any of them...
-
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.
Oh my *god* is that what they're doing? No wonder you're ending up in no-man's land so often! Why are they doing that? Why? For the love of God, *why*?Sync should do a pull, followed by a merge, followed by a push. Period. Non-interactive rebase? Are they trying to be dangerous and terrible, for the sake of stupid shit like "clean history"? Especially since they explicitly don't support
git bisectanywhere, which is the only good reason to do any of that, and even then not automatically?
-
In Git, the philosophy is that you can do whatever you want, and then decide what to share by deciding which commits to push to the outside world. So you work, you commit but check your fucking work while you commit, and then if necessary, you merge stuff other people did and proceed to check your fucking merge before you push.
Which exactly matches the "branch per developer" workflow of every centralized version control system out there. I have nothing against git, I just don't like it when people say that git is inherently significantly better than everything else. The whole "the file is identified by its content hash" thing is pretty useful and is a plus for git, but that's balanced out by git being far less usable than almost everything else.
-
And then there are some that have enough experience to know that VSS supported concurrent checkouts, and worked at companies that didn't suck, and enabled that.
That missed the point. I don't argue that it's impossible to work well with others in VSS, I argue that those who want to be gigantic shitlords choose VSS because it locks by default.
-
Maybe you missed the discussion you had about branching in SVN but it seems a lot more@Jaime said:
Which exactly matches the "branch per developer" workflow of every centralized version control system out there. I have nothing against git, I just don't like it when people say that git is inherently significantly better than everything else. The whole "the file is identified by its content hash" thing is pretty useful and is a plus for git, but that's balanced out by git being far less usable than almost everything else.
Admittedly having never used SVN, I don't know that I believe you when you call Git "far less usable". Looking at the discussion you and @Yamikuronue just had about branching/merging in SVN, it looks a lot more complicated than in Git. I'd call Git's branching/merging stuff another definite plus. Git may take a while to get used to, but if you learn a few commands and get used to a couple of GUI's then it's a breeze to use.
-
Looking at the discussion you and @Yamikuronue just had about branching/merging in SVN, it looks a lot more complicated than in Git. I'd call Git's branching/merging stuff another definite plus.
The scenario we were discussing favors git from a usability perspective because it's "on git's home turf". Git is a DVCS, so it natively works with a "branch per developer" workflow. SVN is a centralized version control system, so "branch per developer" is one of many possible workflows. In the more typical corporate scenario where there is a manager assigning people tasks and developers own certain systems, the git model of committing locally and then pushing to a centralized repo is less usable than simply checking out and committing changes.I find it interesting that you say both "Git may take a while to get used to" and "it's a breeze to use". That's like saying a complicated piece of construction equipment is easy to use because the guy with years of experience is having no problems.
-
Well of course. There are jackasses that think Lotus Notes is great. That doesn't change anything.
-
There was a time when I was a big fan of Bazaar because
-
unlike most DVCS, Bazaar treated a centralized repository workflow as a first-class citizen. I do not remember offhand what it was about the way they handled it that looked better or easier than using any old DVCS and saying "this clone over here is the blessed one." I do, however, remember that there was something that looked like an advantage over that approach, albeit possibly a minor one.
-
at one point there were certain edge cases involving file or directory renames that could make a mess in Mercurial or Git repositories but not in Bazaar. Or to be more accurate, I think it pretty much boiled down to bazaar noticing it had happened and letting you know immediately so you could make sure it had done the right thing with it, whereas in git or hg you might not notice immediately and might need somewhat rarely-used commands in order to figure out exactly what you'd done and how to fix it. I'm not sure, partly because I think both git and hg made that situation easier to deal with later.
-
At one time, it looked like Bazaar would end up with the strongest all-around foreign repository support. There were projects of various levels of maturity to let you use bazaar against subversion, mercurial, and git repos. The bridge to subversion, unlike the ones for Mercurial and (I think, at the time) Git, could push local merge commits back to the subversion upstream...although it did so by abusing svn metadata.
-
Also, for what it's worth, I believe the Eclipse plugin for Bazaar reached the point of being at least as good as tabbing away from eclipse to use another tool before the plugins for mercurial or git did.
Unfortunately, all of those projects eventually stagnated, as far as I can tell. Bazaar itself isn't even under development anymore last I checked. Not that this means it's unusable, but it's not progressing and the plugins I had high hopes for aren't either. And Bazaar, despite Canonical favoring it for a while, never got even the market share Mercurial did, let alone Git.
Opinions on Git and Mercurial are a lot easier to come by, so as far as those go I will just say that when I was becoming familiar with Mercurial, the tooling available for it was in my opinion a valid point in its favor over Git. Now I wish I were less lazy about getting familiar with Git because I would prefer to be familiar with both but think Git would be more valuable.
In terms of personal interest, the other one I'd like to explore some is darcs.
-
-
FYI, we don't use "one branch per developer". I'm a little lost who brought that up first, but it wasn't me.
Yesterday I had a tree conflict. I was attempting to collect a bunch of revisions in dev into a branch cloned from trunk so I could reintegrate the branch to push the project into trunk (prod). This repo is for some testing tools, so there's only a in-flight dev branch and a stable "prod" branch, unlike our usual 4-level environment.
So I made a branch by cloning trunk, then started merging dev revisions into it. I grabbed the revisions, starting with creation of the project folder, through a rename of the project, including a reorganization of the repo that involved moving some folders around, and finally through the latest revisions to the codebase. Tree conflict. I reverted, grabbed half the revisions I had grabbed last time. Tree conflict. I reverted, grabbed a quarter of them. Nothing. The next quarter. No conflict. The top half. No conflict. Okay... whatever. Sure, why not. Reintegrated into trunk. No conflicts.
That's what I mean by random conflicts when merging in SVN.
-
"Branch per developer" came from my replies to others, sorry I mixed it in with your issue.
Anyways, I've made thousands of commits to SVN repositories and I've been tech lead on a team that made tens of thousands of commits during my tenure. That never happened to us. I'm sorry you had a bad experience, but I have no explanation for it.
-
I especially like it when you try to commit a huge tree into the repo and 10 minutes into it there's a synchronization error and then you watch helplessly as everything is reverted back.
-
In the more typical corporate scenario where there is a manager assigning people tasks and developers own certain systems, the git model of committing locally and then pushing to a centralized repo is less usable than simply checking out and committing changes
Yes and no. Here's the thing: Git still gets you tons of benefits over Subversion for that scenario, at least IMO. You still get better management of your working copy (via the index,git add --interactive/--patch1,git stash, etc.) You can still more easily divide that task you get from your manager (which is all but certainly more than a single commit unless you're an jackass) into different, smaller tasks then work on those individual tasks separately, putting them together into a logical coherent whole when you're done. You can still actually do work when, say, on an airplane on the way to a business trip.I'll grant that DVCS as a concept is something that isn't necessary for a centralized environment, and maybe there is really good centralized VCS software. But for many things, I think that Git or Mercurial is a better centralized VCS than SVN even though it calls itself distributed. The main stumbling block (and I'll admit it's a big one) is if you have a repository big enough that you can't reasonably track the whole thing yourself. Because in that case, you have to divide it up into multiple smaller repos, and while there are tools for managing that in Git, they all seem to suck. In SVN you can just dump everything into one repo and do a sparse checkout. The other big drawback to Git specifically (and Hg much less so) seems to have been partially designed to spite people who used other VCSs prior to it.
-
No personal branches in a corporate environment? I'd say think again.
Every BLI and every bugfix is a special type of branch called a transaction, which is versioned on the server. It must be: It is impossible (to the best of my knowledge) to check anything directly into main, or a normal branch. Works quite well, once you're used to the hassle of three-stage merge.
At least most of the approval requirements are turned off for our product...
-
That missed the point. I don't argue that it's impossible to work well with others in VSS, I argue that those who want to be gigantic shitlords choose VSS because it locks by default.
Ahh, I was thinking the other way around, where devs don't even know that any other behavior exists, since they've only worked with VSS in a default installation.
-
I find it interesting that you say both "Git may take a while to get used to" and "it's a breeze to use". That's like saying a complicated piece of construction equipment is easy to use because the guy with years of experience is having no problems.
Good analogy, but you're taking my words out of context so it looks like I'm contradicting myself. What I actually said was:
[quote=toon, post:133, topic:3005]Git may take a while to get used to, but if you learn a few commands and get used to a couple of GUI's then it's a breeze to use.[/quote]
That's not a contradiction from where I'm standing.
Take a forklift: I used to drive one for a living. Forklifts definitely take a while to get used to. They handle differently from most other kinds of vehicle you might drive, such as cars or trucks. You need to know a fair bit about the forklift in question to be able to maintain one. There are even things you need to be aware of, to be able to drive one without seriously risking property damage or human injury. So yeah, I'd say you shouldn't be driving a forklift around other people unless you know what you're doing, and that takes a definite amount of effort.
But would I argue that forklifts are not easy to use? No, I wouldn't. In fact, I'd say at least 95% of all adults under 65 could do it if they were so inclined. Of course, I'd also argue that pallet jacks are much easier to use than a forklift. Basically anyone who can walk upright can use those. But if I need to move a tank of water over dozens of yards of pavement through the rain to the next warehouse, why I can do it with both, but I know which tool I'd consider better suited for the job, and it's not the more easily usable one.
Look, this is a forum where people go, "this person should have his keyboard license revoked". Developing software is a craft, there are ways to do it properly and improperly, and some of the best tools you can have in any craft, take time to get used to, and then all of that time pays itself back tenfold. DBMS'es, web servers, debuggers, IDE's, text editors, even web browsers, it's all the same in that respect, they all come with manuals, and I don't see why VCS should be any exception.
-
But if I need to move a tank of water over dozens of yards of pavement through the rain to the next warehouse, why I can do it with both, but I know which tool I'd consider better suited for the job, and it's not the more easily usable one.
Look, this is a forum where people go, "this person should have his keyboard license revoked".
Yes, some people will do that. Others of us argue this point with those assholes all the time.
-
Sorry @boomzilla, I don't get it... You're trying to tell me something, but I honestly have no idea what it is.
-
Developing software is a craft,
Part of the craft of software development is to make your programs accessible and usable. I would argue that's the most important part of the craft.
If the maker of your RCS (or VCS?) didn't do that, it's a problem for a few different reasons:
-
It communicates to the end-user that they just didn't give a shit about them. It disrespects them and their time right off the bat. If the end-user has a disability that makes use of a CLI difficult, it excludes them entirely for no good reason.
-
It hints that the core of the product you don't see might be just as broken as the visible bits you do see. If they didn't get something as simple as error messaging right (or, like NetBeans, drawing fonts at the correct size), what about the complicated stuff you can't easily see? Is it just as broken? I don't need that kind of doubt in my software.
-
(for a programming tool) It doesn't serve as an example of what good software looks like. There's a large and real risk that when someone has a problem with their UI, they'll say, "well, let's see how Git solved it and do that." Maybe they won't even do this consciously. And now your crappy tool has a ripple effect making thousands of other tools crappy in the future.
and some of the best tools you can have in any craft, take time to get used to, and then all of that time pays itself back tenfold.
Without the learning curve/cliff, maybe it would be paying back twentyfold. This seems to argue for making all software, including developer tools, accessible and usable. Gee, almost like what I've been saying forever.
DBMS'es, web servers, debuggers, IDE's, text editors, even web browsers, it's all the same in that respect, they all come with manuals, and I don't see why VCS should be any exception.
So RCS/VCS should be shitty because everything else is shitty. Brilliant argument.
-
-
Sorry @boomzilla, I don't get it... You're trying to tell me something, but I honestly have no idea what it is.
I agree with you.
-
1) It communicates to the end-user that they just didn't give a shit about them. It disrespects them and their time right off the bat. If the end-user has a disability that makes use of a CLI difficult, it excludes them entirely for no good reason.
A disability like that would also make programming difficult. Seems like a pretty good reason to me?
@toon said:
DBMS'es, web servers, debuggers, IDE's, text editors, even web browsers, it's all the same in that respect, they all come with manuals, and I don't see why VCS should be any exception.
So RCS/VCS should be shitty because everything else is shitty. Brilliant argument.So every book ever written should use one syllable words and pretty pictures of cheerful anthropomorphic animals, because some other books do and those are easier to read! Brilliant argument.
-
So every book ever written should use one syllable words and pretty pictures of cheerful anthropomorphic animals, because some other books do and those are easier to read! Brillant argument.
FTFY
-
A disability like that would also make programming difficult. Seems like a pretty good reason to me?
And the tail wags the dog.
Things are as they are only because people like you want them to remain as they are. Personally, I don't think anybody-- anybody on Earth-- should be excluded from participation in software development.
So every book ever written should use one syllable words and pretty pictures of cheerful anthropomorphic animals, because some other books do and those are easier to read!
If I want to read a book like that, they exist. I can go to the bookstore and find thousands of them.
What if I want a similarly-easy RCS? Where do I find that?
SharePoint - Wikipedia
