The thing that astonishes me the most, is that you just realised what I'm on about. At least we got there in the end. I didn't read the rest of what you wrote, because it looked boring.
That's the thing with git, sure it's not designed for particular use-cases, but people end up using it for those use-cases all the time. Maybe some more thought should have been put into its design - I find that everyone is using this software with quite limited use-cases for everything quite unsettling. It's not as if there aren't better alternatives.
Also, not everything that is interested in things in a repository is a build process. Test systems may wish to pull out only the test areas, for instance.
Look man, you're just a rude and unpleasant person. Perhaps you just play one on the internet, and maybe in real life you're generally lovely and nice to people. It's interesting reading your comments though, they seem to take irrational and weird contrarian viewpoints, and spent most of their time missing the point and insulting people. There's clearly no point actually arguing with you, as the whole 'directories are really files' thing demonstrates. It's entirely irrelevant whether they are, or aren't, because that's an implementation detail, and is of no practical importance when writing actual userland code. Git doesn't track them, end of story.
Please enjoy the rest of your commenting, and do try to be a more pleasant person if you possibly can. It's surprisingly not all that hard, and you might even find yourself liking it.
Hi, Kelvin. I've got a feeling that they do know what they're doing, and they know perfectly well how git works, and what a distributed model means, and I suspect that Microsoft contains lots and lots of people that are much smarter than you and me. Microsoft is not a distributed company, it is a centralised organisation, and - like 99% of the corporate world - has no need of a distributed model.
Of course, if your repo is 300GB, you've done something wrong.
Another very typical response. Why? In what sense is it doing something wrong? Why does doing something that git can't deal with, necessarily doing something 'wrong'? I want to run my unit tests, they consume large amounts of data, I want that data on my machine. What's wrong with that?
It's a feature by design because it allows a developer to work completely offline and only do a git pull when ready to merge branches.
No it's not. Not being able to partially check out code, is not a feature. It's a lack of a feature. There's no reason at all that git couldn't perform partial checkouts, there's nothing in its data model that would prevent it, as far as I can tell, so it's even less of a design 'feature' than you suggest.
This is a typical response to the perfectly well articulated, and one-hundred-percent correct complaints outlined above by petermgreen. He's completely right, git's branches don't actually exist, it's easy to lose commits, it's very hard - the the point of being impossible - to figure out what went on in the past.
But raise all this information, and you'll just be told that you either don't know how to use git - whereas by the time someone knows git well enough to understand where it gets things wrong, they certainly know how to use it. Or, once you get past that particular defense by demonstrating your knowledge to your correspondent's satisfaction, you'll instead to informed that git has no business solving those problems, because those problems don't matter.
Now, I get that Linus created something to solve his particular problems, and I understand that. But the fact is that git was pretty much hacked together over a couple of weeks, and it really shows. Everyone's jumped on it, despite that other options are superior, for no reason that I can completely understand. Probably because it's free.
Oh Kelvin, Kelvin, Kelvin. You could be more wrong, but it would be difficult. That a directory 'is' a file makes no difference to git. If a directory were a file, in any meaningful sense, then I'd be able to write data into it, wouldn't it? I suppose it depends on what your definition of a file is, so for the sake of this particular argument, it's something I can write data into, and stand a good chance of getting it back out again. Can git store empty directories now? No, of course not. Will my instructions, which you followed remember, presumably using the 'real' git, ever actually merge the directory rename into my tree? No, of course not. Or even generate a conflict? Again, no.
Of course you don't have time to figure out who's at fault, since we've already established your busyness, so I'll help you out, and save you some time.
But I renamed the directory 'B' in my branch. So, for instance, the branch decided to move an entire library into another directory. However, my merge did not apply that directory rename to the existing tree, which is what a directory rename should really do, but instead completely ignored it, and only added the (now re-named) file. At the very least, this should generate a conflict. Maybe, say, a tree conflict. Ha. See what I did there?
Anyway, the outcome isn't what I wanted, and is what the text "If you merge in a directory rename, files that you've added to that moved directory prior to the merge, are not moved." means. The same instructions work the same way on different OS's, because this is part of git's implementation, which is to say that it does not track, or even really believe in, directories. Empty directories cannot be stored, as we know, for the same reason. It also doesn't track branches, it just tracks where each of their tips currently are.
I'm using git 2.10.1 on Windows, as it happens, and don't worry, I don't feel like my time is wasted. What's more fun than arguing about near-irrelevant things on the internet? Other than dissing U2, that is.
And lo and behold, the added file is still in the old directory, even though the merged branch had re-named the directory. How about that? I read your link, seems like a very long excuse for being rude to me, but hey, I guess some people are just too damn busy to behave otherwise.
Wait. It's not the square, it's n(log(n)), but still. It's an overhead that's best avoided if at all possible. Which, it turns out, it is perfectly possible to do.
Look mate. If you merge in a directory rename, files that you've added to that moved directory prior to the merge, are not moved. That's the beginning and the end of it, sorry. Fine, I get that git doesn't do that, because it doesn't really believe in directories. no amount of typing 'git status', 'git add', is going to make any difference.
Just because hundreds of thousands of people do something daily, doesn't make it any bloody good. I mean, do you have any idea how many people are listening to U2 right now? Exactly. I rest my case.
I know exactly how git branches work thanks. Directory renames are not supported in merges, even if you use git 'properly', which I am doing as it happens. I also know how git flow works, and I think it's highly overcomplicated and best avoided. Branches increase development time, since every commit to any branch has a cost associated with it that multiplies by the square of the number of other branches, if those branches are eventually to be merged together. That's just the reality of coding with large teams. Technically automated and unit tests can save you here, but not everything is so easily tested.
I've got no idea what broken paths in config files in SVN might be about, but I wasn't trying to defend SVN, I was pointing out that git leaves important metadata unrecorded, allows commits to be irrevocably lost, and doesn't merge anywhere near as well as advertised. Possibly the merging thing is almost an unsolvable problem, since what we really need is a language-aware merge that can deal with conflicts in a single line, by doing per-token merges, or something. But the other complaints stand.
Well, Mr Kelvin, since I wasn't the one who moved the directory, but just the one that attempted the merge, I guess I must be.
I thought git was supposed to do rename tracking all by itself? And also, that it didn't track directories, just files. And in any case, I tested it, and a merged-in directory rename does not move newly added files to that directory, so you're basically wrong. Oh well.
I know perfectly well how git works, thank you very much, and there's nothing in the way in which it's designed that would permit directory rename merges to work.
The trouble is though, that git is actually horrible and dangerous to use, and fails at it first goal, which is to keep your source code safe, no matter what.
I could live with the danger of lost commits, but not with the fact that it's impossible to determine which commit a branch was originally made to. Not that branches actually exist in git, of course, which certainly explains the omission, if not the design.
Git not tracking directories was also a lazy design decision, since directory renames cause carnage when merging.
That's cool that you know what criminals look like, we could just pay you to go through photographs, and we'll just arrest or deport the ones with the bad faces.
the best performance (C) or with a reasonable compromise between abstraction and performance (C++).
No. C++ is used where you need performance and expressiveness and compile-time safety. C is used where you either don't have a decent compiler for your system, or you can't handle the compile times, or you're no good at writing C++.
Not so, computers still are stupid, stubborn machines that need to be forced to behave. And for this, low level languages still reign supreme.
And their operating system, and all the games they love to play? And the code in the ECMs in their car? And anything else that requires deterministic performance? What do you think Chrome is written in? And the V8 javascript engine inside it? Video codes? Media players?
Java is a pig,.NET is nice, but nowhere near fast enough if you really need true performance. Computers aren't really getting any faster anymore, so the only answer to increased performance and workload is learning real computer science principals, and using a language that actually gives you some control over what your computer is doing.
That's partly true. But Linux has no decent photo management software, because there exists no photo management software that touches iCloud photo library (prove me wrong, please, I'd love to see it). And the music player's integration with a music store in OSX and Windows is also something that Linux can't match. Both of those things are a shame, since there's nothing magical about iCloud photo library, and iTunes can certainly be a bit of pig, but if I want to buy an album online and have it show up on all my devices without dicking around at all, iOS and OSX is my only choice. If I want my photo library, including non-destructive edits, to show up on all my devices, even if I don't have enough space on them to download everything, iOS and OSX is also my only choice.
hackers are seriously motivated to find a way in, but for the most part can't
Most of the world's web infrastructure is run by professionals, paid to secure the machines that they administer. Put Linux in the hands of millions of home computer users, and see how long that security lasts.
A chair analogy. That's a new one. Please argue below about the relative accuracy of this analogy within the context of existing car analogies, rather than actually talking about the issues, which we are all capable of understanding here without talking about furniture.
No they won't. Compilers do the 'robot' part, and we're no closer to robotic code generation from high-level requirements declarations than we were when these ideas were first mooted.
Slashdot Mirror
The thing that astonishes me the most, is that you just realised what I'm on about. At least we got there in the end. I didn't read the rest of what you wrote, because it looked boring.
No you didn't, you silly person. You ended up with two folders, I wanted to end up with one, because I'd merged in a folder move. Silly.
That's the thing with git, sure it's not designed for particular use-cases, but people end up using it for those use-cases all the time. Maybe some more thought should have been put into its design - I find that everyone is using this software with quite limited use-cases for everything quite unsettling. It's not as if there aren't better alternatives.
Also, not everything that is interested in things in a repository is a build process. Test systems may wish to pull out only the test areas, for instance.
If I merge in a directory rename, newly added files to that directory are not moved. End of story, you strange and weird person.
Look man, you're just a rude and unpleasant person. Perhaps you just play one on the internet, and maybe in real life you're generally lovely and nice to people. It's interesting reading your comments though, they seem to take irrational and weird contrarian viewpoints, and spent most of their time missing the point and insulting people. There's clearly no point actually arguing with you, as the whole 'directories are really files' thing demonstrates. It's entirely irrelevant whether they are, or aren't, because that's an implementation detail, and is of no practical importance when writing actual userland code. Git doesn't track them, end of story.
Please enjoy the rest of your commenting, and do try to be a more pleasant person if you possibly can. It's surprisingly not all that hard, and you might even find yourself liking it.
They have no idea what they are doing
Hi, Kelvin. I've got a feeling that they do know what they're doing, and they know perfectly well how git works, and what a distributed model means, and I suspect that Microsoft contains lots and lots of people that are much smarter than you and me. Microsoft is not a distributed company, it is a centralised organisation, and - like 99% of the corporate world - has no need of a distributed model.
Of course, if your repo is 300GB, you've done something wrong.
Another very typical response. Why? In what sense is it doing something wrong? Why does doing something that git can't deal with, necessarily doing something 'wrong'? I want to run my unit tests, they consume large amounts of data, I want that data on my machine. What's wrong with that?
It's a feature by design because it allows a developer to work completely offline and only do a git pull when ready to merge branches.
No it's not. Not being able to partially check out code, is not a feature. It's a lack of a feature. There's no reason at all that git couldn't perform partial checkouts, there's nothing in its data model that would prevent it, as far as I can tell, so it's even less of a design 'feature' than you suggest.
This is a typical response to the perfectly well articulated, and one-hundred-percent correct complaints outlined above by petermgreen. He's completely right, git's branches don't actually exist, it's easy to lose commits, it's very hard - the the point of being impossible - to figure out what went on in the past.
But raise all this information, and you'll just be told that you either don't know how to use git - whereas by the time someone knows git well enough to understand where it gets things wrong, they certainly know how to use it. Or, once you get past that particular defense by demonstrating your knowledge to your correspondent's satisfaction, you'll instead to informed that git has no business solving those problems, because those problems don't matter.
Now, I get that Linus created something to solve his particular problems, and I understand that. But the fact is that git was pretty much hacked together over a couple of weeks, and it really shows. Everyone's jumped on it, despite that other options are superior, for no reason that I can completely understand. Probably because it's free.
Oh Kelvin, Kelvin, Kelvin. You could be more wrong, but it would be difficult. That a directory 'is' a file makes no difference to git. If a directory were a file, in any meaningful sense, then I'd be able to write data into it, wouldn't it? I suppose it depends on what your definition of a file is, so for the sake of this particular argument, it's something I can write data into, and stand a good chance of getting it back out again. Can git store empty directories now? No, of course not. Will my instructions, which you followed remember, presumably using the 'real' git, ever actually merge the directory rename into my tree? No, of course not. Or even generate a conflict? Again, no.
Of course you don't have time to figure out who's at fault, since we've already established your busyness, so I'll help you out, and save you some time.
It's git. Git is at fault.
But I renamed the directory 'B' in my branch. So, for instance, the branch decided to move an entire library into another directory. However, my merge did not apply that directory rename to the existing tree, which is what a directory rename should really do, but instead completely ignored it, and only added the (now re-named) file. At the very least, this should generate a conflict. Maybe, say, a tree conflict. Ha. See what I did there?
Anyway, the outcome isn't what I wanted, and is what the text "If you merge in a directory rename, files that you've added to that moved directory prior to the merge, are not moved." means. The same instructions work the same way on different OS's, because this is part of git's implementation, which is to say that it does not track, or even really believe in, directories. Empty directories cannot be stored, as we know, for the same reason. It also doesn't track branches, it just tracks where each of their tips currently are.
I'm using git 2.10.1 on Windows, as it happens, and don't worry, I don't feel like my time is wasted. What's more fun than arguing about near-irrelevant things on the internet? Other than dissing U2, that is.
Doctor Kelvin, I must apologise for having riled you to the extent that you called me a dumbfuck, but here's what I'm talking about.
git init
mkdir A
touch A/file.txt
git add A/file.txt
git commit -m 'a'
git checkout -b Branch
git mv A B
git commit -m 'b'
git checkout master
touch A/file2.txt
git add A/file2.txt
git commit -m 'c'
git merge Branch
ls
And lo and behold, the added file is still in the old directory, even though the merged branch had re-named the directory. How about that? I read your link, seems like a very long excuse for being rude to me, but hey, I guess some people are just too damn busy to behave otherwise.
git add what, Lord Kelvin?
Wait. It's not the square, it's n(log(n)), but still. It's an overhead that's best avoided if at all possible. Which, it turns out, it is perfectly possible to do.
Oh Mr Kelvin, you doth protest too much.
Look mate. If you merge in a directory rename, files that you've added to that moved directory prior to the merge, are not moved. That's the beginning and the end of it, sorry. Fine, I get that git doesn't do that, because it doesn't really believe in directories. no amount of typing 'git status', 'git add', is going to make any difference.
Just because hundreds of thousands of people do something daily, doesn't make it any bloody good. I mean, do you have any idea how many people are listening to U2 right now? Exactly. I rest my case.
I know exactly how git branches work thanks. Directory renames are not supported in merges, even if you use git 'properly', which I am doing as it happens. I also know how git flow works, and I think it's highly overcomplicated and best avoided. Branches increase development time, since every commit to any branch has a cost associated with it that multiplies by the square of the number of other branches, if those branches are eventually to be merged together. That's just the reality of coding with large teams. Technically automated and unit tests can save you here, but not everything is so easily tested.
I've got no idea what broken paths in config files in SVN might be about, but I wasn't trying to defend SVN, I was pointing out that git leaves important metadata unrecorded, allows commits to be irrevocably lost, and doesn't merge anywhere near as well as advertised. Possibly the merging thing is almost an unsolvable problem, since what we really need is a language-aware merge that can deal with conflicts in a single line, by doing per-token merges, or something. But the other complaints stand.
Well, Mr Kelvin, since I wasn't the one who moved the directory, but just the one that attempted the merge, I guess I must be.
I thought git was supposed to do rename tracking all by itself? And also, that it didn't track directories, just files. And in any case, I tested it, and a merged-in directory rename does not move newly added files to that directory, so you're basically wrong. Oh well.
I know perfectly well how git works, thank you very much, and there's nothing in the way in which it's designed that would permit directory rename merges to work.
The trouble is though, that git is actually horrible and dangerous to use, and fails at it first goal, which is to keep your source code safe, no matter what.
I could live with the danger of lost commits, but not with the fact that it's impossible to determine which commit a branch was originally made to. Not that branches actually exist in git, of course, which certainly explains the omission, if not the design.
Git not tracking directories was also a lazy design decision, since directory renames cause carnage when merging.
especially if they look like criminals
That's cool that you know what criminals look like, we could just pay you to go through photographs, and we'll just arrest or deport the ones with the bad faces.
the best performance (C) or with a reasonable compromise between abstraction and performance (C++).
No. C++ is used where you need performance and expressiveness and compile-time safety. C is used where you either don't have a decent compiler for your system, or you can't handle the compile times, or you're no good at writing C++.
Not so, computers still are stupid, stubborn machines that need to be forced to behave. And for this, low level languages still reign supreme.
Very well put.
...those other languages are written in?
And their operating system, and all the games they love to play? And the code in the ECMs in their car? And anything else that requires deterministic performance? What do you think Chrome is written in? And the V8 javascript engine inside it? Video codes? Media players?
Java is a pig, .NET is nice, but nowhere near fast enough if you really need true performance. Computers aren't really getting any faster anymore, so the only answer to increased performance and workload is learning real computer science principals, and using a language that actually gives you some control over what your computer is doing.
That's partly true. But Linux has no decent photo management software, because there exists no photo management software that touches iCloud photo library (prove me wrong, please, I'd love to see it). And the music player's integration with a music store in OSX and Windows is also something that Linux can't match. Both of those things are a shame, since there's nothing magical about iCloud photo library, and iTunes can certainly be a bit of pig, but if I want to buy an album online and have it show up on all my devices without dicking around at all, iOS and OSX is my only choice. If I want my photo library, including non-destructive edits, to show up on all my devices, even if I don't have enough space on them to download everything, iOS and OSX is also my only choice.
hackers are seriously motivated to find a way in, but for the most part can't
Most of the world's web infrastructure is run by professionals, paid to secure the machines that they administer. Put Linux in the hands of millions of home computer users, and see how long that security lasts.
A chair analogy. That's a new one. Please argue below about the relative accuracy of this analogy within the context of existing car analogies, rather than actually talking about the issues, which we are all capable of understanding here without talking about furniture.
No they won't. Compilers do the 'robot' part, and we're no closer to robotic code generation from high-level requirements declarations than we were when these ideas were first mooted.