More stupid Git errors THIS TIME IN FIRST-PERSON!
-
Random git analogy of the day:
You decide you want to drive somewhere so you look into buying a car. There's all these different car models e.g. SUV (SVN), fancy limo (TFS), a sportscar (P4) or a tractor (CVS). Whatever, they all have strengths and weaknesses.
But git is like being handed a transmission, and engine and some wheels and being told: "Hey, here you go, you can build exactly the vehicle you need for your trip—it's not for us to dictate how you make your journey."
And that's great and all, but I don't really want to build a car, I just want to start driving already...
-
To be fair, that's a supervision of junior employees issue, not a source control issue.
What I have been talking about is nothing of the sort. It is all about having the team working as a tightly integrated unit.
The best analogy (not very good I admit) is the human body. While each of the organs are "doing their own thing" any interruption in communication (even for seconds) can have fatal consequences.
-
"Hey, here you go, you can build exactly the vehicle you need for your trip—it's not for us to dictate how you make your journey."
I like the entire analogy....but think it may fall apart if only from the POV that many of the provided parts are not meant to build specific things.....Heck, if you are willing to "go to any lengths" to build anything, all you need are a supply of hydrogen atoms and ALOT of energy.
-
Someone photoshop that Alot cartoon radiating energy, I'm at work and do not have time for making fun of typos.
-
-
Close enough.
-
But git is like being handed a transmission, and engine and some wheels and being told: "Hey, here you go, you can build exactly the vehicle you need for your trip—it's not for us to dictate how you make your journey."
Well OK I guess I'm not using Git "right" then because I've always just used it as it comes, right out of the box. I didn't ever have to assemble anything. Maybe you guys are spending too much time trying to make Git into the old system you used to have, instead of just learning the new system.
-
You must be lucky. I've had horrible screwups the 2 or 3 times I tried to simply use Git right out of the box. It's like I got handed a transmission based on this principle:
-
But git is like being handed a transmission, and engine and some wheels and being told: "Hey, here you go, you can build exactly the vehicle you need for your trip—it's not for us to dictate how you make your journey."
I thought that was ClearCase. Well, except that instead of giving you the parts, it's a lease based on the number of people who ever see the resulting vehicle. (Which is not entirely unlike Wild Wacky Action Bike.)
-
ALOT of energy.
I really wanted to post some image here but I couldn't find any cool alots in Google.Also, Hanzo'd.
-
But git is like being handed a transmission, and engine and some wheels and being told: "Hey, here you go, you can build exactly the vehicle you need for your trip—it's not for us to dictate how you make your journey."
Yeah, well, that's totally wrong analogy you know. First, git works out of the box (though one might be unable to use it). Second, it's not very configurable (most of the options are about what the various commands do by default and not about how the repo works - it's pretty much fixed in this regard).BTW, I don't know how it would ever be possible to have a version control system so modular that you could get entirely different tool just by messing with config files. It's just too complex and interdependent type of software for the Unix way to work.
-
Yeah, well, that's totally wrong analogy you know.
Yeah, well, that's just like, your opinion, man...
Second, it's not very configurable
Aside from the fact that it was a car analogy, it was motivated by an article I read ( http://2ndscale.com/rtomayko/2008/the-thing-about-git ) which would seem to disagree with you:
Git is quite different in this regard. You can work on five separate logical changes in your working copy – without interacting with the VCS at all – and then build up a series of commits in one fell swoop. Or, you can take the opposite extreme and commit really frequently and mindlessly, returning later to rearrange commits, annotate log messages, squash commits together, tease them apart, or rip stuff out completely. It’s up to you, really. Git doesn’t have an opinion on the matter.
-
http://2ndscale.com/rtomayko/2008/the-thing-about-git
At first glance, it seems like written by a git zealot who doesn't acknowledge there might be other VCSs that aren't CSV.The fact you can work with git in many ways is irrelevant. You can do it with other VCSs too if you want. Git isn't partial system - it's a complete, monolithic solution for version control. It's not just an engine and transmission you can choose to build SUV or a sportscar with - it's a complete car, but you can choose if you want to drive it on racetrack or offroad.
-
Alright, how about:
Git is a 4 handle, dual boiler espresso machine – when all they need is instant.
10 things I hate about Git
Git is the source code version control system that is rapidly becoming the standard for open source projects. It has a powerful distributed model which allows advanced users to do tricky things wit…
Filed under: Don't even get me started on how much I hate
-
Git is a 4 handle, dual boiler espresso machine – when all they need is instant.
That's alright I guess. If all you need is instant, then sure, make the instant. But if you are out of instant and you have to use the espresso machine, don't just randomly push buttons on it or assume it works like instant. Learn how to use it correctly.
-
Yeah, that's pretty good analogy. Though FWIW, setting up Git repo is easier than any CVCS. Step 1:
git init. Done.Overall, that's been a pretty good article, but I think that the author has no idea what
git resetmeans.
-
Maybe he doesn't know what reset means but then again it can do at least 4 different things depending on what parameters you give it, so that command is a prime example of git's spotty CLI design.
When I need to do something special I look up reset demystified to make sure I use it in the right mode. More often than not I try to use git-cola to deal with the whole unstaging business, leaving less room for errors.
-
After reading the linked article, I realized that it was me who didn't know about
git reset. Though I never used the various switches except for--hard, and never used it with file path (sincegit checkoutdoes the same thing). I always thought of it as "change the head of current branch, and by default keep all differences between current and requested state as unstaged changes".Also, I find it weird how the article's writer thinks of HEAD. Apparently, it's some global pointer that points to one of the individual branches' head, which is a pointer to last commit in that branch. For me, HEAD is just shorthand for branch's last commit. If I was writing it, this difference alone would make it 20%
coolershorter.
-
You want to simplify HEAD to just the latest commit but you can't, git allows HEAD to point to a ref as well as a commit id (which is now called a "detached HEAD") and hence the abstraction breaks.
That was exactly what the author of that "10 things I hate about git" article was talking about: you need to know all these little implementation details or it is not clear what sub-state your repo is in.
-
Aside from the fact that it was a car analogy, it was motivated by an article I read ( http://2ndscale.com/rtomayko/2008/the-thing-about-git ) which would seem to disagree with you:
The fact that Git allows those things [and to the best of my knowledge there is no way to prevent them] is a problem for those environments where a legal audit trail of "who did what when" is absolutely required.
Many teams can (and should) have people working with only loose coupling. But for most (in my experience) corporate type projects, having robust integration with the fastest cycle times provides a better ROI [which is the reason companies are paying to have the software developed in the first place].
There are a couple of studies that look at the financials of different SDLC approaches in detail. Almost universally, they find that there is no "best way" across the spectrum, but that there are significant and repeatable differences (averaging 17%-25%) when correlation is applied.
-
You must be lucky. I've had horrible screwups the 2 or 3 times I tried to simply use Git right out of the box. It's like I got handed a transmission based on this principle:
ObOT: Apropos of not a lot...
-
Have fun with merging feature branches to trunk after that.
You're one for three, surely you can do better than that.
And for future reference, I'm not defending the poor UI decisions of other version control applications either.
-
But it is special in the sense that it's designed to be used by people who can be assumed to have more technical knowledge than the general population.
Since when does saying "It's for technical people!" give carte blanche for having a terrible UI with inconsistent naming and poor defaults?
If @wood said Discourse was meant for programmers, would that excuse Discourse's UI failures?
-
Since when does saying "It's for technical people!" give carte blanche for having a terrible UI with inconsistent naming and poor defaults?
No idea, maybe you want to ask the guy who said it did.
-
You're one for three, surely you can do better than that.
I can't, since SVN and Git are only VCSs I worked with.And for future reference, I'm not defending the poor UI decisions of other version control applications either.
It's not poor UI decisions - it's poor technical decisions.Since when does saying "It's for technical people!" give carte blanche for having a terrible UI with inconsistent naming and poor defaults?
Technical people are assumed to be able to learn - so, while bad UI is bad just like in every other sector, it's not deal breaker.If @wood said Discourse was meant for programmers, would that excuse Discourse's UI failures?
No, because Discourse doesn't work. Like, there are actual bugs that makes things impossible. There's no excuse for***\****producing 3389dae361af79b04c9c8e7057f60cc6.
-
-
I can't, since SVN and Git are only VCSs I worked with.
In other words, you made a guess and asked a loaded question.
Next.It's not poor UI decisions - it's poor technical decisions.
Have I stuttered at all?
In what what is something likegit undoorsvn undoa technical decision and not a UI decision?
In what way is having command line arguments with different naming conventions a technical decision and not a UI decision?
What about having safety catches disabled by a single character being uppercase, such as-dand-D?Technical people are assumed to be able to learn - so, while bad UI is bad just like in every other sector, it's not deal breaker.
Yes we can learn. Doesn't mean we should ignore its failings.
Doesn't mean we shouldn't deride it for them.No, because Discourse doesn't work. Like, there are actual bugs that makes things impossible. There's no excuse for
***\****producing 3389dae361af79b04c9c8e7057f60cc6.
Funny, that's the exact same way I feel about git sometimes.
-
In other words, you made a guess and asked a loaded question.
I would agree to skip over this issue if you haven't claimed that you cannot break SVN/Hg/TFS repos in the same manner as in Git, which is obviously false, as I have proven for one of three (and my gut feeling is that there exist someone who had similar experiences with other VCSs).In what what is something like git undo or svn undo a technical decision and not a UI decision?
We weren't talking about$VCS_OF_CHOICE undo. We were (or at least I was) talking about SVN's reliance on stringly-typed mergeinfo parameter of files during branching and merging, which is a 100% technical decision and makes a branch basically unusable if it's corrupted, and it corrupts very easily.Yes we can learn. Doesn't mean we should ignore its failings.Doesn't mean we shouldn't deride it for them.
Agreed. But there's much more to VCS than just how easy it is to undo things.Funny, that's the exact same way I feel about git sometimes.
Concrete example or didn't happen.
-
I would agree to skip over this issue if you haven't claimed that you cannot break SVN/Hg/TFS repos in the same manner as in Git, which is obviously false, as I have proven for one of three
I never made that claim. You made the claim that you can fuck up SVN/Hg/TFS repositories in the same way that you can with GIT. You even admitted that you have no idea how it is possible to do it in Hg and TFS.
When you ask a question which requires A to be true, but you do not know if A is true, you just asked a loaded question.We weren't talking about $VCS_OF_CHOICE undo. We were (or at least I was) talking about SVN's reliance on stringly-typed mergeinfo parameter of files during branching and merging, which is a 100% technical decision and makes a branch basically unusable if it's corrupted, and it corrupts very easily
I have only been talking about GIT's UI. In fact the only time I've even mentioned SVN was to say that it doesn't piss me off as much as GIT.Concrete example or didn't happen.
Checkout a case-sensitive repository in Windows.
It will not warn you if there are filename collisions, and instead just silently discard the contents of all but one file in any given group of filename collisions.
-
It's not poor UI decisions - it's poor technical decisions.
It's both, but git is much more solid technically than it is UI-wise. It's just slow and lacks a bunch of features all its competitors have.
-
Checkout a case-sensitive repository in Windows.
It will not warn you if there are filename collisions, and instead just silently discard the contents of all but one file in any given group of filename collisions.How precisely would you handle this situation?
-
How precisely would you handle this situation?
Are you implying that silently deleting user data is the correct way of handling this situation?
Although since the lazy fuckers in charge of this shitty system couldn't be bothered to write an error message with commands that (are guaranteed to) work in Windows (or even write "delete this folder:" so it's relevant to all OSes), I'm not holding my breath.
OS X has case-insensitive file systems available, I wonder what the Mac nerds do. Take their fixie down to the local indie coffeeshop and cry to their barista, I wager.
-
@sloosecannon said:
How precisely would you handle this situation?
Are you implying that silently deleting user data is the correct way of handling this situation?
Although since the lazy fuckers in charge of this shitty system couldn't be bothered to write an error message with commands that (are guaranteed to) work in Windows (or even write "delete this folder:" so it's relevant to all OSes), I'm not holding my breath.
OS X has case-insensitive file systems available, I wonder what the Mac nerds do. Take their fixie down to the local indie coffeeshop and cry to their barista, I wager.
Well, how would you detect it? The filename will be the "same", so even if you ask the OS if it exists, it will appear to. The only way to reliably check that is to actually open the file and check its contents - and doing that is obviously high-cost. I'm not arguing that this is a good UI, but it's actually a really tough problem to solve...
Of course, having both case-sensitive and case-insensitive file systems is really TRWTF
-
How precisely would you handle this situation?
@Salamander said:Checkout a case-sensitive repository in Windows.
It will not warn you if there are filename collisions, and instead just silently discard the contents of all but one file in any given group of filename collisions.Cannot checkout
<commit>because<foo.txt>and<FOO.TXT>are not considered different files on<Filesystem>
You can do<X>in order to checkout one of them specifically, but not both at once.
-
@sloosecannon said:
How precisely would you handle this situation?
@Salamander said:Checkout a case-sensitive repository in Windows.
It will not warn you if there are filename collisions, and instead just silently discard the contents of all but one file in any given group of filename collisions.Cannot checkout
<commit>because<foo.txt>and<FOO.TXT>are not considered different files on<Filesystem>
You can do<X>in order to checkout one of them specifically, but not both at once.Well, how would you detect it? The filename will be the "same", so even if you ask the OS if it exists, it will appear to. The only way to reliably check that is to actually open the file and check its contents - and doing that is obviously high-cost. I'm not arguing that this is a good UI, but it's actually a really tough problem to solve...
can't be Post empty!
-
-
Nope. They blacklisted things in
.git/*and probably just expanded the blacklist to be case-sensitive. You can't blacklist any case-sensitive files if you want to allow case-sensitive files....
-
Well, how would you detect it? The filename will be the "same", so even if you ask the OS if it exists, it will appear to. The only way to reliably check that is to actually open the file and check its contents - and doing that is obviously high-cost. I'm not arguing that this is a good UI, but it's actually a really tough problem to solve...
They made their fucking bed. Now they have to lie in it.
I'm sorry software engineering isn't babytowne frolics. Sometimes hard work is involved. Aw! Poor baby! Go cry to mommy!!!
The problem here is open source fucking LAZY developers refusing to expend ANY effort to make their products bug-free. That's why all open source software is shitty ass crap. (Except, inexplicably, web browsers.)
Of course, having both case-sensitive and case-insensitive file systems is really TRWTF
Having case-sensitive file systems is TRWTF. Whoever came up with that idea should be roasted alive.
-
@sloosecannon said:
Well, how would you detect it? The filename will be the "same", so even if you ask the OS if it exists, it will appear to. The only way to reliably check that is to actually open the file and check its contents - and doing that is obviously high-cost. I'm not arguing that this is a good UI, but it's actually a really tough problem to solve...
They made their fucking bed. Now they have to lie in it.
I'm sorry software engineering isn't babytowne frolics. Sometimes hard work is involved. Aw! Poor baby! Go cry to mommy!!!
The problem here is open source fucking LAZY developers refusing to expend ANY effort to make their products bug-free. That's why all open source software is shitty ass crap. (Except, inexplicably, web browsers.)
Ok. Again - how would you fix it? I can't think of a reasonable way that won't introduce other costs. Checking all files for consistency every time you update or check out sounds to me like an absolutely terrible trade-off because it would take forever...
This may be a conscious design decision. The cost-benefit analysis may have decided this is a "bug" that's not worth fixing, due to the costs fixing it would induce.
-
I never made that claim. You made the claim that you can fuck up SVN/Hg/TFS repositories in the same way that you can with GIT. You even admitted that you have no idea how it is possible to do it in Hg and TFS.
I asked the question "how do you undo similar repo-breaking fuckup?". Keyword: similar. I.e. something that can happen and is appropriate in context of SVN/Hg/TFS. By asking this question, I assumed this is possible to do something like this (because, let's be honest, there is no way one could make completely idiot-proof VCS). Then, you asked a question "how do you cause repo-breaking fuckup?". The tone in which you asked it suggests you thought this question has no answer, i.e. you assumed that there's no way of breaking repo. I continued on the SVN front, since it happened to me once, but stopped talking about the other two since I have no experience with them, but an educated guess can be made that there is some way.I have only been talking about GIT's UI.
Except when you were talking about repo-breaking in SVN/Hg/TFS.Checkout a case-sensitive repository in Windows.It will not warn you if there are filename collisions, and instead just silently discard the contents of all but one file in any given group of filename collisions.
Same issue exists in SVN AFAIK. I'd guess TFS is better in that regard, since it's by Microsoft and main platform is Windows, not Linux. Dunno about Hg.It's both, but git is much more solid technically than it is UI-wise. It's just slow and lacks a bunch of features all its competitors have.
It's so non-sequitur it hurts.
-
Ok. Again - how would you fix it?
Tell you what: when the Git team pays me to fix it, I'll fix it. Before then, it's their fucking problem.
Although it seems pretty easy: the only time it could possibly be a problem is when the Remote is on the case-sensitive file-system, and it only has to check files against files in the directory, so detecting the problem is a breeze. Communicating it to the client is probably shit because "DECENTRALIZED GUYZZZ! DECENTRALIZED!!!!!"
Will that make Git slower? Yes. Measurably so? I highly doubt it. Is Git being slightly slower a good trade-off for NOT INVISIBLY DELETING USER DATA? FUCK YES!
EDIT: probably the hardest problem is figuring out a "lowest-common-denominator" reference of what characters are considered lowercases of other characters in all the various case-sensitive filesystems around.
It's so non-sequitur it hurts.
No I'm just saying if you rated Git's UI on a scale from 1 to 10, it'd be a 1. If you rated it's technical underpinnings (reliability, compatibility, speed, features etc.) it'd be closer to a 5-6 maybe. But both are bad ratings.
-
Although it seems pretty easy: the only time it could possibly be a problem is when the Remote is on the case-sensitive file-system, and it only has to check files against files in the directory, so detecting the problem is a breeze. Communicating it to the client is probably shit because "DECENTRALIZED GUYZZZ! DECENTRALIZED!!!!!"
?
The case sensitivity of the remote has nothing to do with anything....
Git is by definition case-sensitive, even on Windows (there is really no way to change this). All the filenames are stored in the metadata, so the underlying filesystem's case-sensitivity is irrevelvant.
-
I assumed this is possible to do something like this (because, let's be honest, there is no way one could make completely idiot-proof VCS). Then, you asked a question "how do you cause repo-breaking fuckup?"
Yes, you assumed something is possible without even knowing if it was possible. I asked you to backup your claims by giving any evidence that you can cause fuckups.How do you stop X happening in Y?
How do you cause X to happen in Y?
But by all means, do keep trying to shift the burden of proof.
Except when you were talking about repo-breaking in SVN/Hg/TFS
Which happened after you claimed that it was possible to break repos in all three. See above.
-
?
The case sensitivity of the remote has nothing to do with anything....
Yeah it does. You're pulling FROM the remote. So the remote (pullee) has to warn the puller that there's a potential for data loss. The puller has no way of knowing that otherwise.
Git is by definition case-sensitive, even on Windows (there is really no way to change this).
OH HEY LOOK, GIT IS SHITTY AND BROKEN IN ANOTHER NEW WAY! WHEE!
All the filenames are stored in the metadata, so the underlying filesystem's case-sensitivity is irrevelvant.
? It kind of is, if it leads to silent loss of user data.
BTW, thinking about it Git doesn't work on Linux either. Linux doesn't specify what encoding its filenames are in, so Git could easily send a system that only supports ASCII a bunch of UTF-8 characters and silently delete or corrupt data that way.
It only works because there's a convention in Linux OSes to use UTF-8 as the filename encoding. But it's only a convention, it's not in the POSIX spec and AFAIK Linux has no other spec. So Git only works now by accident, not by design.
HIGH QUALITY OPEN SOURCE SOFTWARE FOLKS!
-
Yeah it does. You're pulling FROM the remote. So the remote (pullee) has to warn the puller that there's a potential for data loss. The puller has no way of knowing that otherwise.
What? That's almost TDEMSYR territory....
BTW, thinking about it Git doesn't work on Linux either. Linux doesn't specify what encoding its filenames are in, so Git could easily send a system that only supports ASCII a bunch of UTF-8 characters and silently delete or corrupt data that way.
It only works because there's a convention in Linux OSes to use UTF-8 as the filename encoding. But it's only a convention, it's not in the POSIX spec and AFAIK Linux has no other spec. So Git only works now by accident, not by design.
HIGH QUALITY OPEN SOURCE SOFTWARE FOLKS!
Ok, yeah, now you're just spouting nonsense. Do you really believe that's how this works or are you just BSing us?
-
Ok, yeah, now you're just spouting nonsense. Do you really believe that's how this works or are you just BSing us?
It's the gospel truth. Linux OSes have ZERO specifications on filename encoding. Other than that it ends with a NUL character.
Sorry you're just now learning how shitty and broken Linux is.
-
No I'm just saying if you rated Git's UI on a scale from 1 to 10, it'd be a 1. If you rated it's technical underpinnings (reliability, compatibility, speed, features etc.) it'd be closer to a 5-6 maybe. But both are bad ratings.
And through your ranting you haven't noticed I wasn't talking about Git but about SVN, and not in general but about one very specific thing which is mergeinfo.
-
Yes, you assumed something is possible without even knowing if it was possible.
Yeah, that's basically what heuristics are. That's what allows us to perform good in unknown environments.I asked you to backup your claims by giving any evidence that you can cause fuckups.
And I provided such backup for 1 of 3 things, which makes you at least 33% wrong.Which happened after you claimed that it was possible to break repos in all three.
But before you claimed you were only ever talking about Git.
-
Also - silently deleting files that only differ in case in Git is major fuckup on Git's behalf. Specifically, the Windows port of Git. It is easily fixable - just check each file if there are any conflicts before writing to working copy.
-
so the underlying filesystem's case-sensitivity is irrevelvant.
Actually, NTFS is case sensitive. You just can't use it that way from within Windows.
