More stupid Git errors THIS TIME IN FIRST-PERSON!
-
This industry always standardizes on broken shit. There's even a little slogan for it: "worse is better".
This is why IT is shit.
Well, at least it explains why the standard OS is Windows
-
But I don't want it, I don't need it, and I don't use it. So why the fuck do I even need to know it exists?
Oh yeah: Git is a piece of shit.
You don't even know if you want, need or use "it" b/c you don't know what "it" is. Please go learn.
-
Neither is ok.
But you just said it's OK for programming language? Or is being OK in this regard totally orthogonal to being a good language?Not obvious to me.
Your repo and remote repo are separate repos. It doesn't make sense to lock files since you're the only one that will ever use this repo. That's DVCS for you.That is currently true, that does not have to be true.
Yes it does. You could theoretically make the session with command-line program more interactive, and in some cases it makes sense, but in most other cases it would just get very annoying very quickly. So, except for simple confirmations, or password authentication and similar <abbr title="for a very generous definition of unexpected>unexpected stuff that happened during execution, the interactivity isn't a good thing in most cases. In cases where interactivity would indeed be good, an actual GUI would do a much better work at it - I think you'd agree.A working GUI, that is.
I'm not a copywriter, I'm a software developer.
And that's why you cannot be stupid.And if I may toot my own horn, I type a lot better than most of the fuckers here who don't have dyslexia. Or at least I assume FrostCat doesn't.
https://i2.wp.com/www.troll.me/images/big-empty-room/wow-look-at-all-the-people-who-care.jpgRight.
You seemed to imply that dyslexic people have some difficulty with social interactions. It looked like you messed up the illnesses.1) Every person working with the project has a full copy of the repo (i.e. you can't check-out selected files which is incredibly handle to have)
Not just a copy. They have the repo.And BTW it still downloads the entire repo, so there's no bandwidth/storage savings in using this.
Yeah, on second thought it seems pretty useless. I need to read more carefully in the future.You don't even know if you want, need or use "it" b/c you don't know what "it" is. Please go learn.
I'm pretty sure he really doesn't need offline-ness.
Side note - I'm interested in what operations you consider slow in git, Blakey. I want to run some benchmarks of my own. I take that the opponent should be TFS?
-
@ChrisH said:
It does? Bloody hell.
Hey the timepod's back! Welcome from 4 years ago.heh. We haven't advanced that far into the future yet. We're still on VS2008.
-
I'm pretty sure he really doesn't need offline-ness.
I agree. But learning the core concepts (from e.g. Pro Git) would still be enormously helpful to him. The offline functionality is a natural outcome of the DVCS design. As is basically everything else apart from the stupid names for things.
-
Non-diff-iness is a design choice that has nothing to do with distributedness.
BTW, in the sparse checkout SO thread I linked, there is an answer that solves the "too much data downloaded" problem @blakeyrat has.
-
Non-diff-iness
Did I miss something? What the hell is "non-diff-iness." Mind you I Googled it and there are literally zero results with or without the dashes. That's actually kind of impressive.
-
Your repo and remote repo are separate repos. It doesn't make sense to lock files since you're the only one that will ever use this repo. That's DVCS for you.
That is a "feature" I neither want nor use.
You seemed to imply that dyslexic people have some difficulty with social interactions.
When did that happen?
Jesus Christ people on this forum sure love to put words in my mouth.
Side note - I'm interested in what operations you consider slow in git, Blakey.
Creating a simple commit, say 10 files, on a codebase that's about 50,000 files and about 3.5 GB takes well over 10 seconds.
BTW, in the sparse checkout SO thread I linked, there is an answer that solves the "too much data downloaded" problem @blakeyrat has.
Great. Now point me to the GUI client that implements it.
-
Did I miss something? What the hell is "non-diff-iness." Mind you I Googled it and there are literally zero results with or without the dashes. That's actually kind of impressive.
I don't know the proper term for it so I invented a new one on the spot, one that I thought would make sense to someone who's familiar with git internals. By non-diff-iness, I meant storing particular versions of a file in whole for each revision, not as a diff between parent and current like SVN does.That is a "feature" I neither want nor use.
It's not a feature, it's a basic concept. There's no way to not use it because it would mean not having git repo at all. FWIW,git cloneis probably the best named of all git commands.When did that happen?
When you said, pretending to pretend me, that dyslexics should be chained up in dungeons because they're too stupid to participate in society. Unless you meant that I'm fan of übermensch ideology and would like to everyone more stupid than me - but even in this case, you're exactly just as wrong, because first, I don't think anyone should decide who has right to live, and second, there's no connection at all between dyslexia and stupidity. just like there isn't between dyslexia and social disorders.Creating a simple commit, say 10 files, on a codebase that's about 50,000 files and about 3.5 GB takes well over 10 seconds.
I'll try this. Do you happen to have some idea how long it takes in TFS?Great. Now point me to the GUI client that implements it.
As I mentioned several times already, all Git GUIs suck hard, and you're just hurting yourself by using one. Really, those CLI commands aren't that bad.Another idea - maybe you could try to divide your mods into git submodules?
-
I don't know the proper term for it so I invented a new one on the spot, one that I thought would make sense to someone who's familiar with git internals. By non-diff-iness, I meant storing particular versions of a file in whole for each revision, not as a diff between parent and current like SVN does.
Well that's the problem. I'm not all that familiar with Git internals. I'm familiar with Git concepts as they relate to the UI. If you gave me a two Gits, one with diff-iness, and one without, I don't think I could spot the difference. To me a commit is a "snapshot" of the state of my files [and their history], and how it's stored is irrelevant.
-
Usability is the most important thing in software. By far. By leagues. By universes. The entire point of writing software is for people to use it,
... to produce a result. Usable software is useless if it doesn't produce the correct result.
Usability isn't just ease of use - it's also about how much you can do. If we were to go just by pure ease of use, it would mean Paint is better than Photoshop because it's easier to do things with it.
It's easier to usesource.zip,source_new.zip,source_old.zip,source-old.zip,source_really_old.zip, etc. than it is to use any real SCM, but it's sure as Belgium not better. Ease of use, or even some broader definition of usability, is not the right measure of software quality if the software does not do what needs to be done.
-
It's easier to use source.zip, source_new.zip, source_old.zip, source-old.zip, source_really_old.zip, etc. than it is to use any real SCM
I reject your premise.
-
Note that it's not so much I don't understand DVCS concepts as I ignore them because I have absolutely no need for working offline and so they're useless to me.
You ignore DVCS concepts while using a tool whose entire existence is based on those concepts, then complain about that tool and expect people to take you seriously.
-
Paging @flabdablet: look, someone is ignoring the experience of someone with a natural disadvantage, and needs a white knight to defend them!
-
It's easier to use
source.zip,source_new.zip,source_old.zip,source-old.zip,source_really_old.zip, etc. than it is to use any real SCM, but it's sure as Belgium not better.Actually, if git really does this non-diffy-ness thing, isn't that what it is? Just with extra bits tacked on?
-
Nope, because both old_source and new_source are in the same zip - which makes it smaller as there's a lot of similarity between old and new.
Though all VCS are basically that, at the storage level.
Storing the diff is a way to compress, though it turns out not to be a very good one - the repo ends up larger and slower once there have been many commits, and it appears that merging branches is harder.
(Or just that VCS that work that way are crap at merging)One of my general irritations at most other VCS is how hard it is to branch. Git (and presumably mercurial) assume you will do it a lot, while practically everything else assumes that you will almost never do it.
Case in point - I have no idea how to branch in one of the corporate VCS, as my training never covered it, yet in git I discovered how almost immediately.
Finally blakeyrat: One incredible feature of a DVCS that you should really appreciate is that it is safe to experiment.
You can make multiple clones of real code in a real repo on any disk space you can read & write, then piss about with both of them to learn how the code and the VCS works, and then blow it away when you're done - and you'll never affect anybody else.
You can't do that with any centralised VCS.
-
-
you forgot
source_final.zip,source_real_final.zip, andsource_new_DO_NOT_USE.zip.
-
Just shows how easy those internals are. Definitely easier than SVN's properties mumbo jumbo.
Easy on its own, but still a sub-par solution to the problem of undoing your last action. Significantly harder when you remember that git is like this for pretty much every operation, and you need to know them all.
I know far, far more about git's internals than I do about svn's, and I've used svn for significantly longer than I have git.
Plus, were it any other application, making users trawl through log files to do something as basic as anundowould be grounds for shaming on this forum. But git gets special treatment because git is special.
-
Plus, were it any other application, making users trawl through log files to do something as basic as an undo would be grounds for shaming on this forum. But git gets special treatment because git is special.
And how do you undo similar repo-breaking fuckup in SVN? In Mercurial? In TFS?
-
How do you cause similar repo-breaking fuckups in SVN? Mercurial? TFS?
-
------------------------------------------------------------------------ r76107 | user1 | 2014-01-14 11:46:48 +0100 (Tue, 14 Jan 2014) | 1 line Changed paths: D /labels/TRUNK_UT_label D /trunk IN TRUNK UT label created r75979 ------------------------------------------------------------------------ r76134 | user2 | 2014-01-14 12:04:24 +0100 (Tue, 14 Jan 2014) | 2 lines Changed paths: A /trunk (from /trunk:75978) IN: add accidently removed directory ------------------------------------------------------------------------Have fun with merging feature branches to trunk after that.
-
I am completely unmotivated to defend the blakeyrat persona in any way, because it has a long history of behaving like a completely irredeemable prick.
If somebody else wishes to join the irredeemable prick club by attacking the blakeyrat persona because of its claimed dyslexia, that's also nothing I'm interested in doing anything about.
-
There's no this idle period during the program execution where the user can just dumbly glance at all the options available to him
TIL
Console.ReadKey()doesn't exist.There are plenty of ways the CLI paradigm could be modernised and made more user-friendly, but people who work extensively with the CLI have internalised the current way it works and can't see the possibility of any alternatives
-
There are plenty of ways the CLI paradigm could be modernised and made more user-friendly
Most of which can be made even better if they went full-GUI, so it makes little to no sense to focus on solid interactive CLI experience if you can drop CLI entirely.I'd love to have a good Git GUI.
-
I agree. GUI is better than CLI so focussing on developing CLI is a bad thing
-
forgot to make a joke in previous post
@Jaloopa said:TIL Console.ReadKey() doesn't exist.
We're talking about Linux hardware here, so yes, it doesn't.
-
I was going to link to some Mono docs for
Console.ReadKey(), but I discovered that it is actually broken by default on Linux hardware. Brillant
-
Behind the bluster and bashing, there has actually been some useful stuff in this tread [from all sides]. What I want to focus on is something that was alluded to earlier...
In a corporate environment [where the goal is typically to make the company the most money for the lowest cost over time] is a Distributed VCS a good thing at all???? [For broad spread project with different goals by different people, I believe it is].
Most of the time I coach teams that they should work in bursts of less than an hour (typically 45 minutes) and have their work committed (including testing) so that it is available to all members of the team. This has been demonstrated to provide major benefits.
Unfortunately, a DVCS encourages longer local work cycles, and also (especially with a rebase in git) foster loss of details in the shared knowledgebase. Also, if one is following ALM practices, it becomes very difficult to ensure that any given commit contains only those changes necessary to meet the requirements of a given Task [choosing to use the TFS term, but this applies regardless of tool].
-
What for? I already had the snappy reply.
I know, I shouldn't try to stop you from being wrong. Blakey's gotta rat.
I use it fine.
When were you lying? Now or before? Asking for a friend.
dyslexics should be chained up in dungeons. They're too stupid to participate in society.
Welp...blakeyrat is always right.
-
You seemed to imply that dyslexic people have some difficulty with social interactions. It looked like you messed up the illnesses.
I can think of at least one case...
-
@Salamander said:
Plus, were it any other application, making users trawl through log files to do something as basic as an undo would be grounds for shaming on this forum. But git gets special treatment because git is special.
And how do you undo similar repo-breaking fuckup in SVN? In Mercurial? In TFS?svn is teh suxxors.
Mercurial is trivial. I'd just start work at the place before the fuck-up and close the other (original) branch. Mercurial doesn't have git's detached head issues. It just makes anonymous branches and lets you get on with life.
-
There are plenty of ways the CLI paradigm could be modernised and made more user-friendly, but people who work extensively with the CLI have internalised the current way it works and can't see the possibility of any alternatives
This sounds a lot like a blakeyrant where he thinks that shells haven't changed since the 70s or something.
-
Mercurial doesn't have git's detached head issues.
Programmer working with Git: http://img1.photographersdirect.com/img/262/wm/pd2992109.jpg
-
The funny thing with Git is that even if my head is detached, my commits still land in the right branches. Joys of git-svn, I guess.
-
In a corporate environment [where the goal is typically to make the company the most money for the lowest cost over time] is a Distributed VCS a good thing at all?
For us it isn't. 99% of development is done on-premise or while connected via VPN. The other 1% can be covered by TFS offline mode.
-
In a corporate environment [where the goal is typically to make the company the most money for the lowest cost over time] is a Distributed VCS a good thing at all????
For corporate projects, there will always be one central repository which is the master. The fact that DVCS has a major goal of not having a central master means that there have to be workarounds and hacks. Depending on the VCS, these are more or less egregious but they are always there.
-
For corporate projects, there will always be one central repository which is the master. The fact that DVCS has a major goal of not having a central master means that there have to be workarounds and hacks. Depending on the VCS, these are more or less egregious but they are always there.
Even when DVCS allows you not to have a definite master, there's one anyway because someone has to be in charge of what's actually going out.
-
The funny thing with Git is that even if my head is detached, my commits still land in the right branches. Joys of git-svn, I guess.
Yeah...I just remember that in one of the handful of times I used git, I encountered that situation. I remember reading about what happened and it kind of made sense, but I don't remember the details, and I still prefer the hg way of doing it.
-
Most of which can be made even better if they went full-GUI, so it makes little to no sense to focus on solid interactive CLI experience if you can drop CLI entirely.
Hey look. You reached the conclusion all sane people did back in fucking 1988.
-
The fact that DVCS has a major goal of not having a central master means that there have to be workarounds and hacks. Depending on the VCS, these are more or less egregious but they are always there.
Right; and Git fans also give it as the reason they can't implement stuff like file-locking or partial checkouts, which makes no fucking sense.
Look, I know having "modes" is like cancer and Hitler rolled into one, but why not have a Git mode where it does have a single "master" server that can talk back and forth to the clients? Then they could maybe have feature-parity with your competing products?
PROTIP: if you've made a design decision that makes it impossible to have feature-parity with your competitors, maybe it was a shitty design decision and you should flush it in the toilet post-haste.
-
Plus, were it any other application, making users trawl through log files to do something as basic as an undo would be grounds for shaming on this forum. But git gets special treatment because git is special.
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. A code monkey who only learns enough to do his job will have more problems than the VCS.
-
the reason they can't implement stuff like file-locking
The reason is that they're on a different branch to you, and locking things on other branches than the one you're working on is idiotic.
partial checkouts
Partial checkouts could be done, but they'd also be very complicated behind the scenes and rather strange. Partial commits would also be possible, but would be weirder still (and likely to annoy people). Partial tagging would not be possible. Partial branching makes my head hurt.
Easier to just avoid making mega-repositories in the first place.
-
PROTIP: if you've made a design decision that makes it impossible to have feature-parity with your competitors, maybe it was a shitty design decision and you should flush it in the toilet post-haste.
Begging the question about the desirability of the features to begin with. This is a dark road that you don't want to go down.
-
But it is special in the sense that it's designed to be used by people who can be assumed to have more technically knowledge than the general population.
That doesn't mean I want to waste neurons on memorizing Git commands and quirks!
-
Easier to just avoid making mega-repositories in the first place.
Goddamnit...stop making excuses for why my hammer doesn't have feature parity with my 10-in-1 screwdriver!
-
Begging the question about the desirability of the features to begin with
Why wouldn't it be desirable to be able to check out only the part of the source that you're working on?
-
Easier to just avoid making mega-repositories in the first place.
THE SIZE OF THE REPO IS DICTATED BY THE SIZE OF THE PROJECT!
If Git can't cope with large projects, then YET ANOTHER REASON IT'S SHITTY SOFTWARE THAT'S ASS.
-
But then why is the project so large? If it's so large that neither Git nor TFS behave sanely on it, how are the humans expected to be able to do so?
I'll try this. Do you happen to have some idea how long it takes in TFS?
About half a second, since the changeset only includes changed files. But the server has to be responding and reachable, and no one else can have locked any files you're trying to check in. Then again, TFS doesn't compute the SHA-1 hash of every single file in the work tree every checkin.
-
@boomzilla said:
Begging the question about the desirability of the features to begin with
Why wouldn't it be desirable to be able to check out only the part of the source that you're working on?
I'm not sure. I can't say I've wanted to check out a partial repository. Sounds like doing that is asking for trouble.
