More stupid Git errors THIS TIME IN FIRST-PERSON!
-
Ok, yeah, now you're just spouting nonsense. Do you really believe that's how this works or are you just BSing us?
100% legit. For your viewing pleasure:
$ touch $(printf "\200") $ ls ? $ ls | hexdump -C 00000000 80 0a |..| 00000002
-
Yeah, that's basically what heuristics are. That's what allows us to perform good in unknown environments.
And just because someone only has knowledge of Oracle, it doesn't mean that suggesting you can't store 0-length strings in MySQL is true.
For that you need evidence. Which is the responsibility of the person making the claim.And I provided such backup for 1 of 3 things, which makes you at least 33% wrong.
No, that makes your argument 1/3rd supported by evidence.
Before I asked, I have no way of knowing what you said is true or not, however I am not aware of any issues in any of the three.
So by asking, either I learn something new, or you go super defensive and try to pretend that you're right because you said so.
Or in this case, both.But before you claimed you were only ever talking about Git.
Except for that time where I mentioned SVN doesn't piss me off as much as git. And then later mentioned that I mentioned that SVN doesn't piss me off as much as git.
And this is now a mention of me mentioning that I mentioned that SVN doesn't piss me off as much as git.
-
Actually, NTFS is case sensitive. You just can't use it that way from within Windows.
Pedantic Dickweed Man-- awaaay!
-
And just because someone only has knowledge of Oracle, it doesn't mean that suggesting you can't store 0-length strings in MySQL is true.For that you need evidence. Which is the responsibility of the person making the claim.
0-length strings are very specific thing. Fucking up repo is very general, comparable to storing string data of any kind in DB. Given my experience with MySQL, I'm pretty sure Oracle can store strings too. This is a reasonable buttumption, don't you think?Except for that time where I mentioned SVN doesn't piss me off as much as git.
Oh, right, ambiguous English gramming funtimes. I meant that you indeed started talking about things other than Git only after I made the ridiculous claim that it is even remotely possible to render TFS/Hg/SVN unusable in some way, but your talking about things other than Git started before you claimed that you only ever talked about Git.
-
@sloosecannon said:
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.
100% legit. For your viewing pleasure:
$ touch $(printf "\200") $ ls ? $ ls | hexdump -C 00000000 80 0a |..| 00000002 ```</blockquote> Fack. Not paying attention :barrier: understanding posts. I thought you were talking about Git... Disregard that part of my comment... @boomzilla <a href="/t/via-quote/49928/550">said</a>:<blockquote>Actually, NTFS is case sensitive. You just can't use it that way from within Windows.</blockquote> Yup. I should've clarified - the filesystem's case-sensitivity is irrelevant to *git* and its storage.
-
@boomzilla said:
Actually, NTFS is case sensitive. You just can't use it that way from within Windows.
Pedantic Dickweed Man-- awaaay!
Like it's my fault that MS cripples the way you use their filesystem.
-
Oh, right, ambiguous English gramming funtimes. I meant that you indeed started talking about things other than Git only after I made the ridiculous claim that it is even remotely possible to render TFS/Hg/SVN unusable in some way, but your talking about things other than Git started before you claimed that you only ever talked about Git
Ow. Belgiuming grammar, how does it work?
-
Actually, git will happily create a repo and add that file to it.
-
Yeah. I thought @Blakey was ranting about Git being confused by filename encoding........ So my entire response to that was irrelevant
-
This is a reasonable buttumption, don't you think?
Whether or not it's reasonable doesn't change that the burden of proof is on you to prove that it is true.
You asked a question with implied a statement as fact that "It's possible to fuck up SVN/Hg/TFS repositories".
And I say again: the responsibility to prove that is yours and yours alone.
If you instead said something like "I know it's possible to fuckup SVN, and I think it's possible to fuckup Hg and TFS, so how do you fix it?", that's a whole different ballpark.
And we wouldn't be having this argument.
-
Having case-sensitive file systems is TRWTF. Whoever came up with that idea should be roasted alive.
NTFS is case sensitive, it's just that Windows filesystem drivers (such as ntfs.sys) mask that.
-
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.
And I don't see why detached HEAD prohibits that -- the commit objects are what make up that audit trail you're talking about.
-
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.
Yeah -- keep in mind that you may have no idea what the actual filesystem is -- it could be on some other box over a network share. Furthermore, NTFS supports a fully case sensitive mode in order for SFU to work; this means that even knowing the filesystem type won't tell you if you're dealing with a case-sensitive FS or not.
Having case-sensitive file systems is TRWTF. Whoever came up with that idea should be roasted alive.
Actually, having case-insensitive filesystems can be TRWTF -- have you ever seen the Unicode casing rules? They're belgium-ing insane! NTFS has to keep a casing table on disk because of that...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.
It likely is a conscious design decision not to fix -- fixing it in a non-half-measures way pretty much requires what you're talking about, because FS type 1) may not be known or knowable and 2) isn't a 100% reliable indicator of case-sensitivity.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.
Just wait until you get a NTFS FS with a non-standard casing table in it -- watch everything break! ;)
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.
And considering that NTFS allows the casing table to be set differently on a per-FS basis, that still is not an ironclad solution!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.
Yeah. It only becomes relevant when you checkout a WC from the repo -- a "bare" repository on Windows is a non-problem as far as case-sensitivity goes.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.
No, the fetch operation isn't even the correct time to talk about this! Fundamentally, this is a merge semantics problem at the FS level.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.
The repository will still be fine -- its just that the working copy you check out from that repo will get torched in a rather-hard-to-overlook-completely way. As I've been saying, you don't understand just how hard this problem is.
-
Yeah. It only becomes relevant when you checkout a WC from the repo
How do you check out a toilet?
-
Actually, NTFS is case sensitive. You just can't use it that way from within Windows.
I saw a digital camera that managed to make two folders which only differ by case on an NTFS-formatted SD card. The SD card worked just fine in Windows Explorer, except for the extremely weird situation of seeing two side-by-side folders in Windows named "DCIM" and "dcim".
-
-
git checkout toilet
-
I saw a digital camera that managed to make two folders which only differ by case on an NTFS-formatted SD card. The SD card worked just fine in Windows Explorer, except for the extremely weird situation of seeing two side-by-side folders in Windows named "DCIM" and "dcim".
I'd love to see how that happened...and what the metadata for that NTFS FS looked like.
-
Oh, it's one of those ones where you're meant to be psychic rather than using the most common expansion of an acronym. Gotcha
-
Oh, it's one of those ones where you're meant to be psychic rather than using the most common expansion of an acronym.
No, just the opposite.
-
from where I sit
on the WC?
-
Yeah -- keep in mind that you may have no idea what the actual filesystem is --
How is that relevant?
The machine serving up the repo knows whether it's compatible with case-insensitive or not, that's all that matters.
Furthermore, NTFS supports a fully case sensitive mode in order for SFU to work; this means that even knowing the filesystem type won't tell you if you're dealing with a case-sensitive FS or not.
You're over-engineering the shit out of this.
If NTFS is in case-sensitive mode, it just ignores the warning.
Actually, having case-insensitive filesystems can be TRWTF
Right; computers are only for other computers. Human beings? Fuck them.
No, the fetch operation isn't even the correct time to talk about this! Fundamentally, this is a merge semantics problem at the FS level.
Well it could be advertised during every operation. Why not.
The repository will still be fine -- its just that the working copy you check out from that repo will get torched in a rather-hard-to-overlook-completely way.
Well fine, but then the user says, "ok I finished pulling everything, I can format the server's hard drive now" and OH WAIT he just lost data.
-
-
Well fine, but then the user says, "ok I finished pulling everything, I can format the server's hard drive now" and OH WAIT he just lost data.
Once again, you CVCS thinking creeps in. Your local repo is fine and contains all the data - it's just your working copy that's broken.Yes, it shouldn't be broken. Yes, Git for Windows sucks for this reason. But this particular scenario you presented is impossible.
TRWTF is of course files that differ only in case. Or files named "." (without quotes), for that matter.
-
I do not sit on disk drives.
Fun fact: in Poland, a common term for using a computer is literally "sitting on a computer".
-
Fun fact: in Poland, a common term for using a computer is literally "sitting on a computer".
Prepositions are funny things. We would say "sitting at a computer."
-
Once again, you CVCS thinking creeps in. Your local repo is fine and contains all the data - it's just your working copy that's broken.
How can it contain all the data if:
- Git stores files, not diffs
- It's impossible to store two files with the same name in the same directory?
In any case, what the fuck is the point to the repo storing those files if you can't ever put them in a working copy ever? Wouldn't it be better if Git were just not broken in the first place?
-
How can it contain all the data if:
- Git stores files, not diffs
- It's impossible to store two files with the same name in the same directory
Is this a serious question? A serious answer would be that the git repo does not store the changesets uncompressed inside the repo's directory.
In any case, what the fuck is the point to the repo storing those files if you can't ever put them in a working copy ever?
That would be a good question if it didn't have such an obviously faulty assumption.
-
Is this a serious question? A serious answer would be that the git repo does not store the changesets uncompressed inside the repo's directory.
Look, in my Git discussions here, I've heard "Git stores full files and not diffs" about a krajillion times. Now you're telling me that's not true? WHICH IS IT?
-
Can the ZIP file format store stuff case sensitively? What do ZIP unarchivers do when unzipping case sensitive files onto a filesystem where this would result in conflicts?
-
Look, in my Git discussions here, I've heard "Git stores full files and not diffs" about a krajillion times. Now you're telling me that's not true? WHICH IS IT?
I just told you it didn't store them uncompressed on your hard drive. I don't know the format, exactly, but I know that much, and now so do you!
-
How is that relevant?
The machine serving up the repo knows whether it's compatible with case-insensitive or not, that's all that matters.
Because the machine serving up the repo has no idea what the casing rules of the destination filesystem actually are, and shouldn't care to begin with -- that's the job of the destination to deal with, during working copy checkout and merge.Well fine, but then the user says, "ok I finished pulling everything, I can format the server's hard drive now" and OH WAIT he just lost data.
No, because you have a local copy of the repository. The working copy is scratch space, and only exists locally.1) Git stores files, not diffs
2) It's impossible to store two files with the same name in the same directory?
Because Git uses an internal naming scheme for its repository storage that's not the same as the file names in your working copy, perhaps?
-
Look, in my Git discussions here, I've heard "Git stores full files and not diffs" about a krajillion times. Now you're telling me that's not true? WHICH IS IT?
It was an oversimplication. A mental shortcut. Git doesn't actually store files, like physical files, but it stores file contents. And it does so in all those weirdly named files under .git subdirectory. When it doesn't have to preserve physical instances of those files in the disk filesystem, it gets more flexible about what files are acceptable than the OS it runs on.
-
Because the machine serving up the repo has no idea what the casing rules of the destination filesystem actually are, and shouldn't care to begin with -- that's the job of the destination to deal with, during working copy checkout and merge.
No, because you have a local copy of the repository. The working copy is scratch space, and only exists locally.
italics
Because Git uses an internal naming scheme for its repository storage that's not the same as the file names in your working copy, perhaps?
Fine if that's what it does, but the assholes on this forum have spent like 2 years lying to me about what it does, then.
If you tell me it does X roughly 437284627 trillion times, don't get annoyed at me when I (stupidly) assume it does X.
-
As C# fanboy, you should know how to make proper abstractions and use them. If something looks like a variable, behaves like a variable, and tastes like variable, it doesn't mean it's a variable - it might be a public member function defined in some special way. And you shouldn't think of it. A stream input can come from anywhere - file, internet, /dev/null, user input - but you should be okay knowing it's a stream. If you hear that Git stores files, there's nothing in this sentence that suggest that actual files are created for this purpose.
-
If you hear that Git stores files, there's nothing in this sentence that suggest that actual files are created for this purpose.
Because I am an insane person locked in an institution and nothing makes sense anymore?
-
No - because file is an abstract concept that can be implemented in many ways. It doesn't have to be "saving to current filesystem under matching name" - it might as well be saving to virtual file system, or zipping it, or splitting to parts, or encoded into image, or anything really.
-
-
Fine if that's what it does, but the assholes on this forum have spent like 2 years lying to me about what it does, then.
That's obviously the best explanation for what's happened here.
-
Because I am an insane person locked in an institution and nothing makes sense anymore?
Actually, this would explain a lot of things.
-
Fine if that's what it does, but the assholes on this forum have spent like 2 years lying to me about what it does, then.
You heard an "A" (git stores full files not deltas) and somehow got a "B" (git can't store case-sensitive files on a case-insensitive FS) in your head because you had a pre-existing "A -> B" (the files must be stored under their original names) assumption that was false.
-
It's probably because he still hasn't figured out that the repo and the working copy are two different things. (Which isn't even a Git-specific idea.) He's still all nervous and paranoid from using CVCS's where your precious work lives in the working copy for way too long, and has to survive merges, human error and things without actually being tracked by your VCS.
-
You asked a question with implied a statement as fact that "It's possible to fuck up SVN/Hg/TFS repositories".
I would say the question "How do you X?" implies the question "Is it possible to X?" rather than the statement "It is possible to X." "You can't X," is a perfectly reasonable answer to "How do you X?"
Given the question, "How can you royally Belgium your data in X?" I'd venture to guess that, over the possible values of X, the answer will be "By doing Y" more often that it will be "You can't." You can almost always shoot yourself in the foot if you try hard enough, so assuming you can is probably safer than assuming you can't.
-
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
"rm -fr" would work on Linux, OSX, FreeBSD, pretty much every OS out there except on you #%&@ Windows, so just make your brain work a bit (if that is possible) and translate the damned instruction yourself
-
Actually, since Git for Windows runs in Cygwin,
rm -rfworks just as well here.BTW I always found it funny that some people use
-rfand others-fr. Kinda like on which side you put space in C pointers.
-
"rm -fr" would work on Linux, OSX, FreeBSD, pretty much every OS out there except on you #%&@ Windows, so just make your brain work a bit (if that is possible) and translate the damned instruction yourself
That's a pretty shitty argument. If you're going to make a Windows version, you might as well make it work on Windows as best you can.
(And yes I get that this DOES work on Windows if you're running it in the recommended shell. It could still be better over all.)
-
I would say the question "How do you X?" implies the question "Is it possible to X?" rather than the statement "It is possible to X." "You can't X," is a perfectly reasonable answer to "How do you X?"
It's the only answer when the question requires things to be true when they aren't.
The common example of "How do you stop HardwareGeek from beating his wife?" is a nonsensical question when HardwareGeek doesn't beat his wife or doesn't even have a wife.
-
-
(And yes I get that this DOES work on Windows if you're running it in the recommended shell. It could still be better over all.)
What if it runs only in the recommended shell, and not at all in cmd?
-
What if it runs only in the recommended shell, and not at all in cmd?
What if? Are you actually asking? Because it does run in cmd. Just about as horribly as anything else does. But it does.
