|
down with slavery posted:I'm sorry but if you've been programming for 10+ years and you feel challenged in attempting to use git day to day productively I don't know what to tell you. Swing and a miss. down with slavery posted:I don't care if you don't like it, but being unable to use it productively day to day is not an acceptable reason for a senior software developer to give in any sort of discussion about version control. That is exactly what we are doing, right now. We are having a discussion about version control. The project managers here are saying "it reduces the development teams productivity", the developers here are saying "it's needlessly complex compared to alternatives". You're saying "Anyone who can't use it is weak!". That's why we're heaping poo poo on you. If you can use it day to day, well whoop-de-loving-doo. Use it on your own private projects, see if I care. But if you and I were doing a startup together, and you said "lets use git", I'd say "no, because we have more important things to do then baby the repo all day". If you tried to force it on me, I'd leave you to it and find a better use for my time. It's actually that bad an inconvenience. I know you refuse to see that, but that doesn't make it untrue. DCVS is about working with other people. If you're just working on your own, you may as well use RCS. So here we find ourselves, with you saying that git is some kind of manly IT challenge, and everyone else saying that in a team environment it's a bottleneck that should be avoided unless you actually need its highly specific and situational advantages, and you think you're winning the argument. 
|
#
?
Feb 20, 2014 06:58
|
|
|
|
| # ? May 11, 2024 11:19 |
|
|
Nobody is saying that git is a manly IT challenge. It's not a challenge. It's not difficult. Edit: For example, I've never met in person or worked with anybody that had any trouble getting up to speed with git. Where are these people? Who are these people? How do you find them and can they even code? shrughes fucked around with this message at 07:03 on Feb 20, 2014 |
|
#
?
Feb 20, 2014 07:00
|
|
Sir_Substance posted:
No, I'm saying that if you've been programming for 10 years and git is preventing you from being productive you're probably not very good at your job or being a human being or anything for that matter. I can somehow work with other version control systems, what is it about command line that just makes people shut down? He was being overdramatic and got called out, get over it.
|
|
|
#
?
Feb 20, 2014 07:08
|
|
|
shrughes posted:For example, I've never met in person or worked with anybody that had any trouble getting up to speed with git. Where are these people? Who are these people? How do you find them and can they even code? It's not about being able to make it work. I could probably fly a helicopter if you gave me some time to figure it out. It's about being able to do it rapidly, safely and with a minimum of cognitive overhead. As I said before, version control is there to take the burden away from managing software revisions. You could do software revision control by copy-pasting code into a series of date stamped folders, but that's a loving pain. Every VCS I've used was designed to and has, to a greater or lesser extend, provided an easier and more streamlined system for dealing with that issue. Git was not designed for this. It was designed for managing the linux kernal, and is oriented around that task. It provides in depth, powerful support for subrepo structure and branching on the premise that it will be used to manage a software base which is so large, complex and arcane that it's not reasonable to expect any one person to understand the whole structure at once. It's loving excellent at that. If I was writing an operating system, I too would use git. But that support brings added complexity. It's a totally inappropriate tool for most code bases, because most codebases do not check those boxes, and as a result its branching and subrepo system, held at the fore of the software, are more of an obstacle then an assistance. It's not useless, and it's not impossible to shoehorn it into use in smaller teams and tasks. But it's not the optimal choice for about 95% of all software projects. down with slavery posted:No, I'm saying that if you've been programming for 10 years and git is preventing you from being productive you're probably not very good at your job or being a human being or anything for that matter. Strange, it's like you cant read.
|
|
#
?
Feb 20, 2014 07:17
|
|
Sir_Substance posted:It's not useless, and it's not impossible to shoehorn it into use in smaller teams and tasks. But it's not the optimal choice for about 95% of all software projects. What is? Furthermore, down with slavery posted:What is something that is arcane in git that is not in another command line VCS? I'm not saying their aren't oddities, but that string of commands quoted above has no place in a criticism of git. down with slavery fucked around with this message at 07:35 on Feb 20, 2014 |
|
|
#
?
Feb 20, 2014 07:26
|
|
|
I'm going to argue this, even though you've demonstrated you aren't reading my posts, because I think it's a major problem with a huge number of open source projects. "Good enough" is not good enough for usability. No piece of software is ever impossible to use due to one towering problem, especially in open source. Someone will fix it, or a workaround will be found. Bad usability is created by the placement of 1000 shin high hurdles. Git does not have a towering flaw looming over all that I can point too and go "SEE! BEHOLD THE RED DEMON WITHIN!". The git command system has an endless sequence of flags that subtly modify the process in meaningless ways. Why have the -m flag on commit? Either have people put the commit message on the command line, or have them enter it in vi afterwards. It makes no difference, but the extra flag adds cognitive load to the process. Why make the person add and commit every time? Why not have the add function flag the file as tracked, and have commit add everything unless you say otherwise? It's arse backwards and means you either have to use another pointless flag, or perform an extra command every commit. The git reference page openly says, in the first line, that the git reset command is utterly disgusting. It performs three very different actions with one command, and if you gently caress it up, you can lose code. Stash is gold plating that adds a third place your code could potentially be residing. Useful on occasion, but makes understand the system and knowing where your code is a more demanding exercise then it need be. The git branch command does three different things depending on whether you give it arguments. If you give it no arguments or the -v command, it lists things. If you type something that doesn't start with a switch, it creates a new branch (dont typo!). If you give it the -d switch, it'll delete a branch. I haven't even gotten to the rebase command yet, but I think it's pretty clear what I'm saying. Commands that do totally different things depending on how you use them. Odd flags, some purposeless, some replicating functionality found elsewhere. Not one of these things is insurmountable on its own. I'm not trying to show you some intercal-like command and suggest it's beyond the ken of moral men to understand that one command. The usability is simply, when you look at the entire product rather then laser-sighting one command in an attempt to smokescreen the obvious, a pile of poo poo. There are a score of different, tiny things that taken as one whole make it a disgusting tool I'd rather not use considering there are better options, unless I actually need it's special party trick of ultra-massively distributed VCS. Sir_Substance fucked around with this message at 08:43 on Feb 20, 2014 |
|
#
?
Feb 20, 2014 08:37
|
|
|
Good lord what sort of can of worms have I opened? I agree that git can be confusing at first. You just have to give people good examples of how it can be used with their exact workflow, especially through something they can refer to later like a wiki page of instructions. Once they do the 5 different operations that make up 98% of what they need to do a few times, it really clicks. The biggest contributor to the frustration is usually that the developer is trying to get poo poo done by a deadline but the tools feel clumsy and cumbersome, leading to increased stress levels. That being said, I think I'm going to stick with the rm -rf && git clone for now. I'll learn about what all those commands do some day, too much other poo poo to do right now.
|
|
#
?
Feb 20, 2014 09:15
|
|
Sir_Substance posted:I'm going to argue this, even though you've demonstrated you aren't reading my posts, because I think it's a major problem with a huge number of open source projects. "Good enough" is not good enough for usability. Yes, these are what I would call "legitimate criticisms of git". I'm not saying git is perfect nor the magic bullet, but it's pretty drat good and you have yet to suggest something better, nor explain what arcane command knowledge is required to use git for version control. Give me a task that you feel is too hard in git that's easier in another VCS. You can't point at advanced commands like stash and act like that's a problem, it's just another tool you can use within the git realm to manage your codebase. You never have to use it. Same with the other usages of git reset. Usability has always plagued VCS software and last I checked there are no exceptions. So instead of pointing and laughing at stupid git scripts, why not suggest some better alternatives? I'm all for discussing the pitfalls of git, but I'm confused as to why you have contempt for "developers and all developers like me" because I think it's absurd that someone could suggest that git would prevent them from being productive in a day to day manner? I'm sorry, that's just reality. If you got a new job and they used git, would you quit because you could not work with it? It's just not that bad and the constant moans of "OH MY GOD GIT IS SO HARD" just get old, especially when you don't suggest any alternatives or even offer any legitimate criticisms until you're pushed into a corner. down with slavery fucked around with this message at 11:04 on Feb 20, 2014 |
|
|
#
?
Feb 20, 2014 10:56
|
|
|
Being a longtime TFVC user, the most confusing (and biggest benefit) in switching to Git was the more flexible branching/merging. Partially this was because I was used to TFVC-style mostly flat version histories, where branching and merging could only happen along carefully preconfigured paths. I've had a project where that became a major trouble spot. The customer had submitted a bunch of change requests, and we implemented them all. But some of them relied on other backend systems getting updated, so we couldn't merge them into UAT and production in the same order that they were implemented. Some of them could get delayed, and one major one never made it to production. Removing it from the UAT branch after it had been there for months was a big headache. Merge conflicts were big and frequent, and there was at least one instance where unapproved code made it all the way into production and broke important features. A more flexible branching system would have helped a lot there. If I had to re-do that project with Git, I would probably have had each feature development take place in a separate branch, which would help keep all changes related to a specific change request organized neatly. They'd still get merged back to the development, UAT and production branches the same way as with TFVC when everything went smoothly, but I could use checkouts, rebases and cherry-picking to reorder, add or remove entire sets of changes more easily than with TFVC.
|
|
#
?
Feb 20, 2014 11:10
|
|
|
down with slavery posted:but I'm confused as to why you have contempt for "developers and all developers like me" Oh, sorry, let me clarify. That has nothing to do with git. You said the following: down with slavery posted:I thought this was the version control thread not the "confess your weaknesses" thread There are lots of developers who like to place themselves on some kind of abstract programming leaderboard. Points are theoretically conferred within this clique by perceived skill and knowledge. I stand outside it and look on with disgust. Work that should be simple is frequently ruined by architecture astronauts trying to get more points on this leaderboard by using the latest design pattern, even when it's not needed, at the expense of readable, flexible, functioning code. Tools that should be maintainable aren't because the guy who implemented them used the latest FOTM platform instead of the standard one to get more points from his peers. Documentation is neglected, feature creep expands because everything has to integrate with everything, all because people are more worried about how other developers think of them then how good their software is. The worst part is, there is no leaderboard. It's a total fiction that exists only in these peoples heads, yet induces the kind of behavior where they make provocative statements like down with slavery posted:I thought this was the version control thread not the "confess your weaknesses" thread and think that this is in some fashion normal behavior that will make other developers respect them and their opinions.
|
|
#
?
Feb 20, 2014 11:56
|
|
|
hirvox posted:If I had to re-do that project with Git, I would probably have had each feature development take place in a separate branch, What is really disturbing is that there are people developing software right now that don't use a separate branch for each (non-trivial) feature. Sir_Substance posted:There are lots of developers who like to place themselves on some kind of abstract programming leaderboard. Points are theoretically conferred within this clique by perceived skill and knowledge. The superiority claimed is not in knowing how to use git. Nobody believes that's anything special. Nobody is valuing and 'down with slavery' seemingly isn't valuing having knowledge about git or the present ability and skill to use git. What people here opine, rightfully, is that people who struggle with git's interface or its concepts, and continue to do so weeks and months into working with it, are abject retards. Nobody is saying, "Oh, I'm so much better than these retards." They aren't on the radar, on any sort of abstract programming or practical programming totem pole at all.
|
|
#
?
Feb 20, 2014 12:05
|
|
|
shrughes posted:The superiority claimed is not in knowing how to use git. Nobody believes that's anything special. Nobody is valuing and 'down with slavery' seemingly isn't valuing having knowledge about git or the present ability and skill to use git. What people here opine, rightfully, is that people who struggle with git's interface or its concepts, and continue to do so weeks and months into working with it, are abject retards. Nobody is saying, "Oh, I'm so much better than these retards." They aren't on the radar, on any sort of abstract programming or practical programming totem pole at all. shrughes posted:People who find this confusing are not qualified to be programmers. No, you're right. There is no totem pole, and you're definitely not trying to sort yourself to the top of it. 
|
|
#
?
Feb 20, 2014 12:20
|
|
|
What the gently caress are you talking about? Here, let me clue you in on something, Ithaqua was making a dramatic gesture. TFS very well may easier to learn but if the best benefit is "it looks like a normal windows file structure" then it's not really much of an argument about the VCS software in my eyes. So again, I'll ask you. What's something hard to do in Git that's way better done somewhere else? What are the alternatives and why?
|
|
|
#
?
Feb 20, 2014 12:23
|
|
|
down with slavery posted:What the gently caress are you talking about? You actually agreed with me above, and now you're back on the warpath, looking for more points by circular argument. Totem pole. I like it as a phrase. This is the point where I'm just banging my head against a wall. I've said my piece, and I stand by it. Do as you wish now.
|
|
#
?
Feb 20, 2014 12:36
|
|
|
Sir_Substance posted:You actually agreed with me above, and now you're back on the warpath, looking for more points by circular argument. Totem pole. I like it as a phrase.  In what way is a totem pole metaphorically related to a circular argument, unless you're pulling some True Detective "time is a circle" bullshit here.
|
|
#
?
Feb 20, 2014 12:39
|
|
|
I keep seeing the "git reset does three different things" argument. What? It does one thing. Or rather, it does a double operation: First, moves the "current revision" pointer somewhere else, and then updates the working copy (in a more or less destructive way) to match that new current revision. This could sound very similar to the "git checkout" command,except that checkout won't let you destroy data in the current working copy. So it makes the distinction pretty easy. Need to work on a different branch? "git checkout". Need to go to somewhere in the past? "git reset".
|
|
#
?
Feb 20, 2014 12:48
|
|
|
shrughes posted:What is really disturbing is that there are people developing software right now that don't use a separate branch for each (non-trivial) feature. Git by comparison creates a much cleaner working folder. And because branching (and usually merging) is such as lightweight operation, it can be used routinely.
|
|
#
?
Feb 20, 2014 12:58
|
|
|
down with slavery posted:What the gently caress are you talking about? The biggest benefit of centralized version control over distributed version control is that the overall workflow is simpler. Get code from central repo. Make changes. Merge if necessary. Check in. It very rarely deviates from that, which is good when your company consists of hundreds or thousands of developers of wildly differing levels of experience, skill and dedication. These are folks that don't want or need the power (and associated workflow complexity) that DVCS delivers. New Yorp New Yorp fucked around with this message at 13:03 on Feb 20, 2014 |
|
#
?
Feb 20, 2014 12:59
|
|
Ithaqua posted:The biggest benefit of centralized version control over distributed version control is that the overall workflow is simpler. Get code from central repo. Make changes. Merge if necessary. Check in. It very rarely deviates from that, which is good when your company consists of hundreds or thousands of developers of wildly differing levels of experience, skill and dedication. These are folks that don't want or need the power (and associated workflow complexity) that DCVS delivers. I mean, isn't that what git is though as well? git clone <repo> git checkout <branch> make changes git commit -ma <message> git push How is this any less simple than quote:Get code from central repo. Make changes. Merge if necessary. Check in. The fact that Git is a DCVS doesn't even have to come into play for most people. Also, there are GUI tools that can achieve all of these things for the command line averse as well, on both Windows and Mac.
|
|
|
#
?
Feb 20, 2014 13:02
|
|
|
The problem that started this argument and the problem with git's perception, in my opinion is this:
Then you can start using and understanding the commands to do what you want to do. Each repository is a unique scenario and requires knowledgeable application of the git toolkit in order to solve the specific problem. You cannot just go on StackOverflow, find what you think is the same problem, and copy and paste the commands. It will at best delay the problem, not further your understanding and at worse break something. You're effectively a gardener, managing a large tree*, and you have a bunch of tools with which to do it. This tree is different for each gardener and no other gardener can fix your tree unless they work on it themselves. It's like a doctor trying to diagnose a medical condition over the phone with a child. What little I know of git makes people's cries that it's arcane, or complicated or unproductive seem like they simply don't understand the model. I won't deny that you will break things and have to spend a fair bit of time to get to the right level of understanding, but the rewards outweigh the obstacles vastly. * I don't mean the data structure, I mean the organic object as a metaphor for the data structure which is of course a directed acyclic graph, duh!!!! o.m. 94 fucked around with this message at 13:52 on Feb 20, 2014 |
|
#
?
Feb 20, 2014 13:46
|
|
|
down with slavery posted:You can't point at advanced commands like stash and act like that's a problem, it's just another tool you can use within the git realm to manage your codebase. You never have to use it. Same with the other usages of git reset.  "I don't understand the problem. You can still pick files fine, you just don't have to use any of the other options."
|
|
#
?
Feb 20, 2014 13:52
|
|
MononcQc posted:
The command line impaired usually see something more like this:  Note the lack of reset option
|
|
|
#
?
Feb 20, 2014 13:58
|
|
|
I have never used a GUI for git, but the command line feels exactly like the image I posted. A million commands to do a million things with a thousand options to give a billion possibilities. It's powerful alright. It's just neither elegant, intuitive, nor easy to use. You have to suck it up and go plow through it, invest the time to memorize all the little elements of it. Git people telling you it's usable if you stick to the basic commands is like Vim people telling you vim is approachable if you just start it in INSERT mode and don't press <Esc>. It hides very little of the beast behind it and you know it's still there, with all of its unfriendliness.
|
|
#
?
Feb 20, 2014 14:02
|
|
MononcQc posted:I have never used a GUI for git, but the command line feels exactly like the image I posted. A million commands to do a million things with a thousand options to give a billion possibilities. And that is why GUI tools exist. For those who would like to abstract away those powerful features and just "work". You can't go to the command line and complain about having too much power. Is there a more approachable command line VCS that doesn't suffer from similar issues?
|
|
|
#
?
Feb 20, 2014 14:04
|
|
|
hg is a very obvious candidate here.
|
|
#
?
Feb 20, 2014 14:08
|
|
|
Linux is the clearly superior OS, and if your developers can't figure out how to use it they are dunderheads. More seriously, if we're giving anecdotes, the only developer on my last team with a serious problem with git was the one who used to (and probably still does) copy around folders as his source control, and gave great commit messages like "fixed" when doing his weekly check in on Friday.
|
|
#
?
Feb 20, 2014 15:06
|
|
|
nielsm posted:I keep seeing the "git reset does three different things" argument. What? It does one thing. Or rather, it does a double operation: First, moves the "current revision" pointer somewhere else, and then updates the working copy (in a more or less destructive way) to match that new current revision. echo "Hi there" >> foo git add foo git reset foo Is that a third thing reset just did? (The current revision pointer is still HEAD dirty, the working copy still has "Hi there" at the end of the file foo)
|
|
#
?
Feb 20, 2014 15:13
|
|
|
fletcher posted:That being said, I think I'm going to stick with the rm -rf && git clone for now. I'll learn about what all those commands do some day, too much other poo poo to do right now. And this is what this entire problem with git boils down to, laziness. You don't want to learn, so you don't, and you complain about it like it's gits problem. But it's not, it's your problem.
|
|
#
?
Feb 20, 2014 16:00
|
|
|
I find this seeming hatred of git odd. Then again, I've only really worked with CVS and git, and git utterly blows away CVS. I cannot think of anything I did with CVS that git does not make easier and simpler.
|
|
#
?
Feb 20, 2014 16:24
|
|
|
|
|
#
?
Feb 20, 2014 17:10
|
|
|
As a systems administrator this is pretty much the kinda stuff I hear constantly from every developer I've ever worked with.
|
|
#
?
Feb 20, 2014 18:05
|
|
|
Megaman posted:And this is what this entire problem with git boils down to, laziness. You don't want to learn, so you don't, and you complain about it like it's gits problem. But it's not, it's your problem. Yup it's laziness
|
|
#
?
Feb 20, 2014 18:17
|
|
|
Deus Rex posted:unless you're pulling some True Detective "time is a circle" bullshit here. Horseshit, time is a cube
|
|
#
?
Feb 20, 2014 19:16
|
|
|
Sir_Substance posted:The git command system has an endless sequence of flags that subtly modify the process in meaningless ways. Sir_Substance posted:Why have the -m flag on commit? 2. Because CVS, Subversion, Mercurial, and likely many other systems take the "-m" flag and they all have the same meanining. One fair complaint of Git is that it's commands are dissimilar to older/other revision control systems. Sometimes there's good reason for that. However "git commit -m" is perhaps the least surprising behavior of git. Sir_Substance posted:Why make the person add and commit every time? Say you need to fix some bug. To do so requires making changes across three files that logically form a single commit--if for no other reason, the code will fail to compile unless the changes to all three files are present. Sometimes it's convenient to run "git add foo" after finishing the changes to the first file, before working on the next two. Doing so keeps the changes in the first file from appearing in subsequent "git diff" calls, where the output can get quite large if there's lots of changes. It will also warn you if any further changes are made to that file after running "git add", which may often be a mistake. But sure, some folks would find having to run "git add" all the time to be inefficient, which is why the commit "-a" flag exists. Now, say you need to do a branch merge and there's merge conflicts. Files that auto-merge cleanly get added to the index automatically. Files that have merge conflicts that have to be manually resolved are not added to the index. Thus, "git status" makes it very clear which files need to be manually fixed, and you indicate that the merge conflict is resovled by running "git add" on those files. Here, other revision systems (e.g., Subversion and Mercurial) require you to do the same thing, and indicate that merge conflicts are resolved before committing. The difference is they use specialized commands for this purpose (e.g., "svn resolved", "hg resolve -m") whereas git (re)uses the same operation that's consistent and familiar in other contexts. Maybe the point is that folks don't have to resolve merge conflicts often, and so Git's approach is heavyweight for the "common" case. I might argue that's because merging can be so difficult in other revision control systems that folks avoid doing it as much as possible. Sir_Substance posted:The git reference page openly says, in the first line, that the git reset command is utterly disgusting. It performs three very different actions with one command, and if you gently caress it up, you can lose code. Also, it's actually quite difficult to lose code in Git. Even if you derefence them, commits will still hang around in the repostiory and can be accessed by their commit hash, and they'll be listed in the reflog. Sir_Substance posted:The git branch command does three different things depending on whether you give it arguments. Sir_Substance posted:I haven't even gotten to the rebase command yet, but I think it's pretty clear what I'm saying. At some point folks are going to have to learn how to use a tool to become proficient with it. I suppose there's a question of whether such tools are worth learning in the first place, but the past 30 years of software development suggests they absolutely are in order to stay ontop of non-linear development efforts with short timelines. ExcessBLarg! fucked around with this message at 19:44 on Feb 20, 2014 |
|
#
?
Feb 20, 2014 19:38
|
|
|
shrughes posted:Edit: For example, I've never met in person or worked with anybody that had any trouble getting up to speed with git. Where are these people? Who are these people? How do you find them and can they even code? git supports a wide range of possible workflows, and some of them need a much wider range and more sophisticated command of the git space than others, if you're used to one going to another can be a bit of a shock without a cheat-sheet or something.
|
|
#
?
Feb 20, 2014 19:47
|
|
|
So you feel shocked, then get a cheat-sheet, and use it. What's so hard about that?
|
|
#
?
Feb 20, 2014 20:04
|
|
|
Requiring git add for already-tracked files is a consequence of Git having a staging area for the next commit. This staging area (and thus the need to git add files that are tracked) is not an implementation detail that should be hidden; it is a feature. It allows for easy implementation of operations like "only stage some of the textual changes in this file, leave the rest unstaged":code:
|
|
#
?
Feb 20, 2014 20:14
|
|
|
Except that git add is not required unless you are actually adding a file to the repository. You can do git commit -a and it will automatically add all modified/deleted files to your commit without ever typing add. I don't really recommend it because I think it's way better that you learn to add things manually, but you certainly don't have to. It really is true that like 95% of arguments against git I read are made by people who clearly have never used it in any real capacity.
|
|
|
#
?
Feb 20, 2014 22:08
|
|
|
Assuming I'm reading the man pages right, just about anything you do with git add and then git commit, you can do in a single step with git commit and the right flags (including only committing specific chunks with git commit -p). So the only thing that the index adds (no pun intended) to git is the ability to take your time in putting together a complex commit. E: F,b.
|
|
#
?
Feb 20, 2014 22:09
|
|
|
|
| # ? May 11, 2024 11:19 |
|
|
down with slavery posted:Except that git add is not required unless you are actually adding a file to the repository. I never do 'git commit -a' because plenty of times if I have four modified files I want one to go in one commit, two to go in the next, and then I want to "git checkout -- " the fourth, and "-a" seems like a really bad habit to get into. Maybe I'm the horror (especially since we use gerrit and I'll have to squash those commits eventually).
|
|
#
?
Feb 20, 2014 22:15
|
|