Blakeyxkcd and the years and years of struggling with broken software that just so happens to use git
-
That's actually pretty good, then. A lot better than anywhere I have worked, that's for certain.
-
I'm way too late but wanted to chime in.
I agree with some posters that git is technically great: fast, powerful and flexible. I love the sheer speed and rawness of it.
But it has godawful UX. They expose implementation details everywhere. Commands are only logical if you think in how it's implemented, which also happens to be the first thing all git tutorials teach: the bleeding DAG.
Well, hello! It's so obviously wrong to do that to your end users. And IMO anyone who has ever written software should be able to see this and agree that the UX is pretty crap, despite its powerfullness. Kinda like a kit car. But noo, most programmers are freaking complexity junkies who love to brag about their supposed natural understanding of complexity and are scared shitless of being exposed as less than stellar minds. So they defend tools like Git and claim that it's obvious to them. Well guess what, I get Git as well and I still thing that the UX is bloody crap!
I get this type of behaviour all the time, and it drives me nuts. I try to describe to some other programmer how some tool or library is needlessly complex for what it acheives and how a simpler tool would be much more effective for our use case. The smug bastards always proceed telling me how "easy" it is for them to deal with the complexity and want to be helpful and show me their ugly crap code which solves a perfectly simple problem in some Rube Goldberg way with classpathscanners, annotations and global variables. No matter how hard I push they maintain that this is a perfectly fine way of coding because "it works, what is it that you don't understand?". Gaaaah!
With this attitude, no wonder that 90% of all software projects are failures. Where are the really smart people who are actually smart enough to realize that complex does not equal powerful and that you are better of not bogging yourself down with peripheral unneccesarily complex stuff?
-
... this is a perfectly fine way of coding because "it works ...
Code that works is the lowest level of "good code".
Code that is readable is the next.
Code that tends to not expose bugs when enhanced is the third.If a programmer is happy with writing code that works, but no better, I don't want them working with me. A level zero programmer is one that doesn't often successfully write level one code. A level "negative one" coder is one that doesn't agree that it's worth it to ever write code that's better than "it works".
So, when I hear "it works" as a justification, my only response is usually "your standards are too low".
-
No one here claims git has a good UI. Just that it is what it is, and you need Google handy. If you develop a sgit and clean up the CLI interface it might even replace it. Make your UI idioms consistent with intuitive command names, that are discoverable and I will switch to your
sgit.
-
I agree with some posters that git is technically great: fast,
I keep seeing this and going whaaaaaaaa?
I think Git's only fast if your repo is < 10 MB.
-
Code that works is the lowest level of "good code".
Code that is readable is the next.
Code that tends to not expose bugs when enhanced is the third.Doesn't matter if the product is unusable?
Or are you folding usability into "works"? Because I can guarantee none of the developers of Git are doing that.
-
When I said UX, i was mainly referring to the CLI, because the UIs (except maybe gitk) isn't really git's responsibility.
-
No one here claims git has a good UI. Just that it is what it is, and you need Google handy. If you develop a sgit and clean up the CLI interface it might even replace it. Make your UI idioms consistent with intuitive command names, that are discoverable and I will switch to your
sgit.These attempts may have one of two results:
- When encountering certain remote situations, your tool handles just as awful as git. Your users hate you and go away.
- When encountering certain remote situations, your tool fails completely. Your users have to fall back too git, hate you, and go away.
-
It's a million times faster at merging, checking in, , branching, pushing etc than CVS and SVN, the ones I was mainly using before git.
-
But wait, are you on anything but Windows? Because Git's Windows port tends to be a lot slower due to the inefficient compatibility layers they used.
-
I stopped using Windows after XP SP2, mainly on Linux for dev and sometimes on OSX.
-
I do not see any harm to make git CLI syntax consistent. To make it straight forward to remove a remote branch instead of pushing an empty ref.
When encountering certain remote situations, your tool fails completely. Your users have to fall back too git, hate you, and go away.
I am not suggesting any new git, same git but with a sane and memorable syntax. There should be simple commands for simple usage.With a
git saneadd-on:git sane remove remote branch mybranch
-
If a programmer is happy with writing code that works, but no better, I don't want them working with me
Management is usually pushing me to sacrifice anything above "code that works" for the time-to-market gods. They even use the term "time-to-market" in english to make it sound like a more legit buzzword.
-
Management is usually pushing me to sacrifice anything above "code that works" for the time-to-market gods. They even use the term "time-to-market" in english to make it sound like a more legit buzzword.
The first rule for a business is to make money, all those technical debts we as developers hate fails in comparison with the actual debt. So yes, sometimes something that works is simply better than something that will work.
-
It's a million times faster at merging, checking in, , branching, pushing etc than CVS and SVN, the ones I was mainly using before git.
Ok, well that experience is directly opposed to mine.
Making it worse, due to Git's stupid design, you can't check out portions of the repo, it's all-or-nothing. So not only is Git slower with big local copies, but it REQUIRES the local copy to big as big as possible.
-
Or are you folding usability into "works"?
Variant for UX:
UI that works would be level 1 - git.
UI that has good feedback - level 2
UI that is discoverable - level 3.
-
I think Git's only fast if your repo is < 10 MB.
I work with some repos that are more than 200MB and Git is fast.
You are a liar !
-
Management is usually pushing me to sacrifice anything above "code that works" for the time-to-market gods. They even use the term "time-to-market" in english to make it sound like a more legit buzzword.
That's why the development team needs to make maintainability non-negotiable. A respectable builder wouldn't give you a quote for a house that will look horrible in five years. A respectable development team shouldn't quote a solution that isn't built properly.
-
I work with a repo of 8GB and about 30 000 files, committing or doing about anything is certainly not zippy on Windows.
-
It's a million times faster at merging, checking in, , branching, pushing etc than CVS and SVN, the ones I was mainly using before git.
In my experience using SVN and TFS repositories that are in the 100's of MB - the only way to be significantly faster would be to go back in time.
-
I work with a repo of 8GB and about 30 000 files, committing or doing about anything is certainly not zippy on Windows.
Our repo is 13.5 GB and 31,482 files (although some of those files aren't checked-in, that count includes things like Visual Studio .user files). It's slow as shit.
Subversion might be slower with a similarly-sized repo, but the nice thing about SVN is I can only check-out the folders I actually need, and it stays snappy as a result.
-
But wait, are you on anything but Windows? Because
Git'sWindowsporttends to be a lot slower due to the inefficientcompatibilitylayers they used.FTFY
-
Yep, the monolithic repo is a problem which everybody loves to deny due to gits supposed "architectural beauty". Combine that with the inability to branch parts of the repo, the suboptimal submodule system and the (up until recently) lack of a decent solution for large files and you're in for a good ride.
I think that people like git because it's distributed nature puts the developer in control. No pesky sysadmin or change controller which saboutages your workflow for job security.
But it comes at a price: the lack of locks is one. The monolithic repo is another. Those shouldn't be unsolvable problems. But most people just like to argue that everything is fine and dandy with their favourite tool, like people earlier in the thread arguing that locking is wrong. IMO it might not be the preferred way of working, but it sure is handy! I personally detest when someone puts their favourite tool on a pedistal and refuses to admit that it has flaws. Why would you even do that? A decent engineer should have an open mind about the pros and cons of things, but maybe I'm just dreaming.
-
But it comes at a price: the lack of locks is one. The monolithic repo is another
There is really no monolithic repo, but instead a truly distributed work flow. For the same reason, there is no need for locks if you consider why git was developed. git is designed for the sole pleasure of Linux kernel developers: it is designed having in mind multiple trees and a central authority to merge patches posted to the mailing list to the tip branch of core maintainer. GitHub and Gitlab have re-tooled git and thus you see the need for locks. Git without PR does not make sense, because it is the workflow (yes many people use it like a DropBox of some sort). With PR in mind you do not need locks.
-
That's twisting my words. You know what I mean by monolithic.
Also, locks do have uses. Not if you are solely versioning mergeable files, but this is a very idealistic worldview you are pushing.
-
Oh but what if two people independently edited a non-mergeable file as blakeyrat mentioned. Pull requests won't get you out of that mess.
-
That's twisting my words. You know what I mean by monolithic.
Yes I like twisting words :-)Please look at the link, it shows how to use PRs properly
Oh but what if two people independently edited a non-mergeable file as blakeyrat mentioned. Pull requests won't get you out of that mess.
The idea is that whoever merges the PR knows exactly what he is doing.
-
Yes well even if he reviews both changes to be perfectly valid and great, there is no way for him to accept both. That's the point. He cannot merge the changes. He will have to choose one. Maybe those were PSDs or enterprise architect savefiles or whatever. The only way of solving the issue is to ask one commiter to redo all their changes based on the other persons file.
-
The idea is that whoever merges the PR knows exactly what he is doing.
It doesn't matter how much he knows what he's doing, he's still going to have to throw away someone's work.
-
He does not have to accept both. He can merge one, then politely ask the other PR to re-base their change on top of his branch again. If that means re-doing the work, it is the process to blame not the tool. If the document has non-binary diff-able format (documents are fine as long as they are odt or newer formats) they can be even automatically merged, but if they are not the product manager should be fired immediately.
It doesn't matter how much he knows what he's doing, he's still going to have to throw away someone's w
Having locks is expensive. It depends on the contention, if there are few developers that might work, but the larger the size of a project the more expensive they become. You are protecting a resource from multiple access, and not using the proper tool for that.
-
He does not have to accept both. He can merge one, then politely ask the other PR to re-base their change on top of his branch again.
... which means they have to do the work over again. Which was exactly what I said.
If that means re-doing the work, it is the process to blame not the tool.
-
In a lot of companies, the tool is the process
-
Even if you say this is a process problem, other source control systems can enforce process that Git can not. Making Git an inferior product.
If the document has non-binary diff-able format (documents are fine as long as they are odt or newer formats) they can be even automatically merged, but if they are not the product manager should be fired immediately.
Wow. Have you ever run-- nay, worked at-- a company? An actual revenue-generating company?
You're saying my boss should be fired immediately because he picked SQL Server data files to store the reference data needed by our unit tests, for a product that's based around SQL Server.
Having locks is expensive.
Who gives a shit?
It depends on the contention, if there are few developers that might work, but the larger the size of a project the more expensive they become.
Ok. Who gives a shit?
You are protecting a resource from multiple access, and not using the proper tool for that.
What is "the proper tool"?
-
-
Sorry but it sounds like you don't understand the problem. Think of a JPG where I modified the picture in one way and you in another other. How to rebase your picture changes on mine?
Edit: ok you got the problem but still want to deny it existing. Great. It doesn't take away from that it's still an effing lacking feature in git!
I don't paricularly like locks and never use them, but I can certainly acknowledge that it's a lacking feature which some people find useful. And when you start talking about contention, come on! A few people clicking in GUIs being a contention problem???? Besides, most VCSes use advisory locks anyway.
And to bite back a bit, git technically already contains locking, albeit an optimistic one.
-
There is a white background, I add a cat and my evil coworker adds a dog, the merge is adding cat besides the dog.
It is an excel sheet, I add a line and you add a line and column, the merge is adding 2 lines and a column. Some times merge does not even make sense, in which case 2 people working on the same file is product management
. You can send an email and ask people to avoid touching your file, which is not any different from a remote lock.
-
You can send an email and ask people to avoid touching your file, which is not any different from a remote lock.
You don't even fucking know how other source control systems work, you hack.
-
Look, you started out by saying that git is fine if you consider it to be specifically for Linux kernel development.
I think that is kind of a moot point. You cannot just accept every product for what it is and not criiticize it or compare it with similar products. I at least find that a very foreign way of thinking.
I choose git because I like it better than the alternatives, but I would never try to convince people who need to coordinate access to their binary files that they are wrong! Think about it, if you were doing some project with friends, would you hire a project manager or mail everyone "Urgent! I'm using a43.jpg until 10:43. Please don't touch it until you've pulled branch blah". No, you would either say "we'll live with potential conflicts" or choose another VCS which supported advisory locks if you found it important.
All I'm saying is that nothing is perfect and people have to effing acknowledge that and understand that fanboyism isnt doing anyone any good.
-
Ok, I concede you are right and I was trolling, yes having a lock will be helpful.
Think about it, if you were doing some project with friends, would you hire a project manager or mail everyone "Urgent! I'm using a43.jpg until 10:43.
Ok. I never have had to deal with this hypothetical situation. For my use-cases the files have always been diff-able and occasional binary files are created just by one person. It is a different usecase to use git for versioning entire files and not changes/diffs to parts of it.
-
Ok. I never have had to deal with this hypothetical situation.
i.e. you're using it as a toy on toy projects for baby-infants. With a team size of one.
-
I have used it for small to medium sized projects. But only for source control. We do not post cat pictures to our git.
-
And you don't work with databases, because it's a toy project for baby-infants.
-
you post your databases to git? Or maybe you mean sqlite files? We use postgresql and we never have to push anything binary to git.
-
And you don't work with databases, because it's a toy project for baby-infants.
A lot of us work with databases but don't have crazy issues like you do. I don't work with git, but having giant binary blobs to represent data like that makes me feel ill regardless of source control.
-
Well I'm sorry to hear about your SEVERE PSYCHOSOMATIC ISSUES but they are not my problem.
-
Here, have a like notification and a reply notification.
-
Here, have a like notification and a reply notification.
What are you, some kind of furryphobe?
-
-
Doesn't matter if the product is unusable?
Not strictly related to the quality of the code. Something could be coded brilliantly but still awful to use, or code that just barely works and takes days to do a minor change could compile into an application with the world's greatest UI. Truly great software needs both, of course
-
You've never had a pre-commit hook give you an extraordinarily-vague message like, "tag missing from source" which turns out, after wasting like 5 hours of your time, actually means, "commits to branches named after bugs need to have the bug number in the comment".
Sounds like a "I don't know how to follow my company's rules for checking in code" problem, not a git problem.
I keep running git add --all && git status because it tells me whether or not I have fixed all merge conflicts. Then, I compile, fix any other issues, and git commit to conclude the merge.
git mergetool? Hell, you can even specify what software to run with it.I do agree that putting the merge conflict contents in the file is retarded as hell though. Is it really that hard to write it out as a .merge file? You're already copying the old file to .old!
So Bob spends 2 weeks editing "2015 forecast.xlsx". Two days after he starts, Sally begins her edits to "2015 forecast.xlsx" and it takes her two weeks as well. Now we merge.
... oops! I have to pick EITHER Bob or Sally's version! Which means, no matter what, OUR COMPANY JUST WASTED TWO ENTIRE WEEKS OF LABOR BECAUSE OF ITS SHITTY BROKEN SOURCE CONTROL PRODUCT. Gee, imagine how nice it would have been if Bob could have simply put some kind of lock on that excel file before he started.
Bob and Sally should be reprimanded for checking Word/Excel/Powerpoint documents into a source code repository instead of something like Sharepoint.
I say this as someone who worked on a project that, at one time, had hundreds of Excel documents checked in to source control, so I'm TR
I only squash or rebase when another developer asks me to do it in order to get a PR accepted.
I only fixup when I notice I made a minor error that has no reason for belonging in a separate commit.
Our repo is 13.5 GB
That's TR
-
Sounds like a "I don't know how to follow my company's rules for checking in code" problem, not a git problem.
Until that error came up, I didn't even know that rule existed.
The awesome fun is that if you mention TWO Jira tickets in a commit's comment, like "PD-237 fix a regression in Blah caused by previous fix to PD-194", you won't be allowed to check-in the code (with an incredibly vague and useless error message, natch) unless both tickets are open. That one took ages for me to figure out.
Bob and Sally should be reprimanded for checking Word/Excel/Powerpoint documents into a source code repository instead of something like Sharepoint.
What if it's part of the product? Like release notes?
I say this as someone who worked on a project that, at one time, had hundreds of Excel documents checked in to source control, so I'm TR
There's nothing wrong with having Excel documents checked in to source control. At least, there was nothing wrong with it before Git suddenly became the hot shit.
That's TR
Why?
-
The awesome fun is that if you mention TWO Jira tickets in a commit's comment, like "PD-237 fix a regression in Blah caused by previous fix to PD-194", you won't be allowed to check-in the code (with an incredibly vague and useless error message, natch) unless both tickets are open. That one took ages for me to figure out.
Really the problem isn't the rule, it's that whoever wrote the hook didn't account for any edge conditions.
Hooks are a WTF in the first place.Like release notes?
They should be on a storage server somewhere with a link to download them?
There's nothing wrong with having Excel documents checked in to source control.
Except there's no way to competently merge the files.
You're asking me why having 13.5G of source code for a single project is a bad thing?
-
They should be on a storage server somewhere with a link to download them?
Instead of in the product's installer?
Except there's no way to competently merge the files.
That doesn't matter, if you could FUCKING LOCK THEM WHICH IS WHAT WE ARE TALKING ABOUT.
You're asking me why having 13.5G of source code for a single project is a bad thing?
It's not all source code. But generally: yeah. Why is that a bad thing?
