Someone poked Blakey about Git again



  • @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    I would rather say that it is because the Git core developers are maintainers and power users, so they churn advanced features, but since they are used to shell, they don't write any Guis for them.

    They don't have to. All they have to do is wrap the main Git functionality into a DLL so other people can. They have to do the BARE MINIMUM, and they still haven't bothered. (Even worse: they have one internally, but don't bother to build or publish it in shared library form.)

    The only rational conclusion you can draw here is that they hate (with a passion) their own users.



  • @gwowen said in Big list of software that cannot handle spaces or accents in paths:

    Yes. As I explained very carefully earlier - they're writing this software for their needs (and more importantly their notion of usability).

    Their notion of usability is the guy who didn't build a wheelchair ramp, then sits at the window yelling insults at the poor guy in a wheelchair trying to get in the building.

    THIS IS NOT SOMETHING YOU OR ANYBODY SHOULD BE DEFENDING.

    Like... how can I even communicate to you how much of an asshole you are being right now? It seems impossible that this situation could exist, but here we are.



  • @cark said in Big list of software that cannot handle spaces or accents in paths:

    What git doesn't do is source control, or whatever the hell everyone seems to think it does. It does one thing and one thing only: git. Any application to source control should be seen as a side effect of what git actually doing, which is git. Once you accept that, you can start to learn how git may be used to do source control

    That's actually a healthy and good attitude to have.

    The problem is: for that to work, Git still needs to be equipped with an API. That's all anybody's asking for. I don't care if they keep the CLI interface as-is. Just make the program accessible for people who want to make different UIs for it.



  • @cark said in Big list of software that cannot handle spaces or accents in paths:

    But it does work and lets me do what I want, much easier than any other tool I've used

    What other tools have you used? Like... HittingBallsWithLumpHammer 2.0?



  • @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    Their notion of usability is the guy who didn't build a wheelchair ramp, then sits at the window yelling insults at the poor guy in a wheelchair trying to get in the building.
    THIS IS NOT SOMETHING YOU OR ANYBODY SHOULD BE DEFENDING.

    Strawman, X-Box-Live shouty-boy.



  • @gwowen said in Big list of software that cannot handle spaces or accents in paths:

    Good Lord, your post is such an embarrassing collection of strawmen, raging incoherently against things that bear no resemblance to anything I said. At this point, you've essentially debased yourself to the point of a 12 year-old shouting swearwods on XBox Live.
    Get some fresh air, find a job you don't hate, and try not to be such an asshole so much of the time.

    I like how you're not addressing any of the actual points I made.

    Does this mean you've reconsidered and now believe that Git being required as a condition of employment while also being entirely inaccessible to the disabled is a horrible thing that nobody should cheer on? But you can't admit it to save face?

    I hope so.



  • @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    I like how you're not addressing any of the actual points I made.

    You've already made it perfectly clear you've no interest in that, except to rephrase it as juvenile strawmen. So I'm not going to engage with that puerile tactic. I have no interest in debating with children, I have one of those at home. (Albeit a child with a better grip on anger-management than you - but then he is two).

    Go get laid, or whatever it is you do to release your rage besides screaming on the internet.



  • @gwowen said in Big list of software that cannot handle spaces or accents in paths:

    Strawman, X-Box-Live shouty-boy.

    Ok first of all, no it's not. Git is inaccessible to a large proportion of the population.

    Second of all, is the fact that I own an Xbox somehow an insult? What the fuck is up with that? "He download Thief from Xbox Games With Gold! Let's mock him for that!"

    @gwowen said in Big list of software that cannot handle spaces or accents in paths:

    You've already made it perfectly clear you've no interest in that, except to rephrase it as juvenile strawmen.

    What strawman do you think I set up here? Do you even know what that word means?

    The only one I can think of is you're somehow denying that people incapable of using a CLI exist? Is that it?

    Well guess what: you're wrong. I'm one of those people. It's not a strawman, it's my own personal experience.

    And shout-y as these posts may be, every single click of the bold or italics button has been more than earned by that piece of shit software that's made my professional life a living hell for 5+ years now. If anything, I'm not raging enough.

    Not that I expect you to understand, since you're obviously incapable of standing in anybody else's shoes. (And I'm just some idiot who owns an Xbox which is, apparently, worthy of derision? Seriously what the fuck is up with that?)



  • @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    Second of all, is the fact that I own an Xbox somehow an insult?

    It was a reference to this.

    At this point, you've essentially debased yourself to the point of a 12 year-old shouting swearwods on XBox Live.

    Which is all you've ever reminded me off. An extremely angry 12-year-old with a ridiculously inflated opinion of himself.



  • @gwowen Regardless of how many Xboxes I own (3), the points I made above are legit.

    Since you stopped addressing them and turned to only ad hominem attacks, I can only assume you now agree with them.

    I'm happy to have helped you to new understanding, and I hope you will be more thoughtful about what terrible software you choose to defend in a public forum in the future.



  • @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    the points I made above are legit. I can only assume you now agree with them.

    Declare victory and move on. Always a good plan. Hope you got a "Mission Accomplished" banner.


  • Banned

    @RaceProUK said in Big list of software that cannot handle spaces or accents in paths:

    @gwowen said in Big list of software that cannot handle spaces or accents in paths:

    As I explained very carefully earlier - they're writing this software for their needs (and more importantly their notion of usability).

    If they didn't intend for Git to be used outside of their little group, why is it available to the public?

    Why not?


  • FoxDev

    @Gąska said in Big list of software that cannot handle spaces or accents in paths:

    @RaceProUK said in Big list of software that cannot handle spaces or accents in paths:

    @gwowen said in Big list of software that cannot handle spaces or accents in paths:

    As I explained very carefully earlier - they're writing this software for their needs (and more importantly their notion of usability).

    If they didn't intend for Git to be used outside of their little group, why is it available to the public?

    Why not?

    Because you don't release internal tools to the public.



  • @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    Oh, so they're selfish assholes! That justifies everything. Everybody loves selfish assholes.

    To be honest, Linus describes himself this way



  • @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    They all can call into shared libraries, too.

    No, not really. Usually the shared library has to provide interface that obeys certain rules that are different for each of them. Windows have COM, which is mostly language-independent, but there is no such thing on other platforms. Process with pipes is platform independent.

    And then there is the question in what you can implement the DLL. You can write an executable in almost anything, but few languages beyond C and C++ compile into DLLs (.NET assemblies, despite being called .dll, don't count, since they can't be opened using the same API).

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    So everyone using Git from the CLI is using it "relatively easily"?

    I am not sure about everyone, but whatever I've done was easier with git than anything else I used. And I used cvs, arch, clearcase, subversion and tfs. All those were harder to write some utility on top than git.

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    Human interfaces
    Programming interfaces
    Those two needs are MUTUALLY-EXCLUSIVE.

    That does not preclude either of them to be a command-line interface. In Git, both are. Yes, they are mixed together and yes, it is confusing. But those git commands and options that are intended for scripts are rock solid. More than most library interfaces I've seen anyway. See, git maintainers won't break their own scripts. They have zillions of them.

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    Windows has COM and WSH. Apple has AppleEvents

    So they have exactly nothing in common. Not helpful.

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    There's one feature Git has that other source control projects do not: you can work offline.

    svk, monotone, mercurial, bazaar, fossil, bikeeper, darcs … can all do that. No, that is not the interesting feature.

    What about reflogs? Stage with interactive add? Rebase? Interactive rebase? Pickaxe? Bisect?

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    (And that's not even true for TFS-- TFS 2013 had that.)

    From version 2013, TFS uses GIT as version control component. So of course it can work offline. It is GIT (the original version control component is kept around, but I am pretty sure they didn't add any features to it).

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    Oh, so then I can lock a file so other people can't stomp over my changes to a binary file like in TFS and Subversion, right?

    That is obviously rather incompatible with distributed systems. But in fact, yes, there is an extension for git that does that.

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    What about the feature were I can download just a tiny subset of the entire repository?

    No. That feature is mostly incompatible with distributed version control—and therefore you won't find it in any distributed system, not just git.

    Yes, I know many projects that had huge repositories in Subversion and where they switched to git, they usually split them to components. It usually turned out to clear things up a bit too.

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    THEY HAVE MORE FEATURES THAN GIT.

    Yes, there are some features that distributed systems, including git, don't have. And there are even some projects where those features are useful. I actually did use locking for Rhapsody models and then for Creative Suite (Flash) projects. But both sucked for more reasons than just that they needed exclusive checkouts to use.

    I don't remember ever checking out part of a Subversion or TFS repository that was not a well defined module.

    Oh, that's just two features. Didn't you promise

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    There's about a half-dozen features SVN, TFS, etc have that Git does not.

    at least four more?

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    Are you confusing the word "feature" with the word "confusion" or perhaps "annoyance"?

    No, I am not.

    And by the way, most Git features I regularly use, that don't exist elsewhere (rebase, pickaxe, reflogs, interactive add, bisect), don't exist because there would be something special about the underlying git model. They exist because git is easy to script (and because it is quite fast).

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    "accessible by those with disabilities"

    Command-line can be used with both braille terminal and screen reader just fine.

    Or do you mean it figuratively?

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    In fact, Photoshop which is more powerful than GIMP is also significantly more usable.

    And that, precisely, breaks your argument. Because you now can't tell whether graphic designers prefer photoshop for its power or for its usability. Better example would be Blender.

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    Except some people are incapable of using a CLI interface, just as some people are incapable of climbing stairs.

    Given the similarity between programming and using CLI, programmers shouldn't be those people.

    Yes, I can imagine other types of users who would have trouble with it. But those are different use-cases, with different requirements. And Git is not suitable for them. And the maintainers never claimed it is. It was always marketed as software version control system.

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    For Joe Random Developer it might be needless. Those who only need to update and commit and call it a day don't need any of that complexity and risk unnecessarily running into it.

    ... and yet they're exposed to it anyway.

    Wow! It's almost as if you admit it's a shitty product right here, and yet somehow still inexplicably are defending it.

    Because in a software project, most users actually end up taking on at least some of them and never look back.

    And yes, that is practical experience from projects I worked on. Once the option to use git-whatever on top of the official system, most people picked it up and never looked back. And they could just return, because everything still ended in the official system. And they did come with question how to do this or that about complicated things. But usually these still turn out way easier in git than in whatever, so nobody comes back anyway.

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    They don't have to. All they have to do is wrap the main Git functionality into a DLL so other people can.

    There is zero relation between whether it is an API and whether it is a DLL. Git has an API that involves invoking processes, sending them input and reading output. Making it into a DLL would not make it any more stable. And it is mostly stable anyway.

    The citool uses the command-line just fine. So does gitk (that does have some issues with memory leaks, but that looks like a bug one could do with any kind of API). So does TortoiseGit. And Git Cola. And Git Extensions. And …

    I believe Visual Studio actually uses libgit2. Anyway, since they added git as the preferred version control component in TFS 2013, Visual Studio can do everything with Git that it can do with TFS (ok, except locking files probably; I never used that in TFS either). Eclipse can also do everything with Git it can do with Subversion and TFS. Idea/WebStorm/CLion/AndroidStudio… can also do everything with Git they can do with Subversion—and more then they can do with TFS, because they don't have TFS plugin. And so on for most programming tools.

    And most colleagues I knew and know still go to the command line for git. And they clearly don't have to, because the basic features are all accessible from the GUI and they could easily avoid the advanced ones. So the only explanation is that they actually find it easier once they get the grip of it.

    Note: I am always talking about programmers and software project. Git is not suitable as a document filing system. It is not suitable for managing video collections. The maintainers don't claim it is. In fact, they don't claim it is suitable for anything at all. Software engineers tend to use it anyway. Software companies tend to use it because programmers keep demanding it, not because the management would order it. Git does not have sales representatives to that would take the CTO to an opulent dinner and a night club, so CTOs don't have incentive to order it.



  • @El_Heffe said in Big list of software that cannot handle spaces or accents in paths:

    Car analogies are the Rolls Royce of analogies.

    Rolls-Royce, the company known for cars that it does not make.


  • FoxDev

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    No, not really. Usually the shared library has to provide interface that obeys certain rules that are different for each of them. Windows have COM, which is mostly language-independent, but there is no such thing on other platforms.

    Apart from the fact that every system quite happily makes use of shared libraries with pure C exports.



  • @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    And that, precisely, breaks your argument. Because you now can't tell whether graphic designers prefer photoshop for its power or for its usability.

    Let me explain his argument for you. It doesn't matter why designers prefer it. The point is that photoshop is both powerful and easy to use, and it proves that you don't need to sacrifice usability.


    Why nobody is talking about gitextensions? I found it so easier to use than anything else for git.



  • @RaceProUK said in Big list of software that cannot handle spaces or accents in paths:

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    No, not really. Usually the shared library has to provide interface that obeys certain rules that are different for each of them. Windows have COM, which is mostly language-independent, but there is no such thing on other platforms.

    Apart from the fact that every system quite happily makes use of shared libraries with pure C exports.

    These days most languages do have some kind of binding, usually via libffi. But once you want to pass more than primitive types, it gets tricky with memory ownership and packing the data and such and the end result is that it definitely isn't simpler than text-based IPC.

    And that only covers one side. How do you wrap a python function in a DLL? A perl one? A Java one? A Shell one? That direction is just as important.



  • @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    That does not preclude either of them to be a command-line interface.

    It does if you want either to be non-shitty.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    In Git, both are. Yes, they are mixed together and yes, it is confusing.

    It also guarantees their shitty UI can never be improved in the future. Great.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    But those git commands and options that are intended for scripts are rock solid.

    Are they? How come the error messages that they return when Git inevitably fucks up aren't machine-parseable, then? That's something it's kind of necessary for an API to have. (Actually ideally the error messages would be structured data, but using your moronic "API via. CLI" you don't have structured data, because it's shitty and stupid.)

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    So they have exactly nothing in common. Not helpful.

    Not helpful to whom? For what purpose?

    For writing a GUI around a library/utility program they're extremely helpful. And again: I don't want to be punished because you chose to write your product in a really shitty OS that doesn't have a feature like this.

    I'm sorry that porting your product from your primitive 1970s OS to an OS that these "new" (1990s) useful features is so difficult, but you fucking made the bed, now lie in it.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    What about reflogs? Stage with interactive add? Rebase? Interactive rebase? Pickaxe? Bisect?

    I don't want to be flogged even once. (Although it is a great name, because using Git is roughly as painful as being flogged.)

    I'm not sure why the concept of "staging" files you think is so exciting. ("Interactive add", as opposed to what? A robot does it for you?)

    Rebase is just a bunch of errors waiting to happen.

    I've never heard of "pickaxe" and I think you made it up.

    Every source control system I've ever used has bisect or equivalent.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    From version 2013, TFS uses GIT as version control component. So of course it can work offline. It is GIT (the original version control component is kept around, but I am pretty sure they didn't add any features to it).

    TFS had offline before it integrated with Git.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    That is obviously rather incompatible with distributed systems.

    It's not obvious to me. To me, it's just a pain in the ass that makes Git entirely unsuitable for a lot of my use-cases. Like putting Skyrim mods under source control.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    No. That feature is mostly incompatible with distributed version control—and therefore you won't find it in any distributed system, not just git.

    So they're making their technical issues into MY problem.

    Look, Git's distributed. Whoop-de-shit. "Distributed" means "fewer features". Why do you accept that as gospel? Why couldn't Git operate simultaneously in "distributed" and "online" modes and thus have ALL the features at the same time? Most companies I've worked with that use Git use it only online anyway.

    It's not like God came down with a stone tablet that read "distributed source control tools can not have online modes!", that was a decision made by a human being.

    Again: they chose their own shitty design. If that design prevents them from adding some useful features, why do I have to suffer?

    "Git has all the features of previous products! ALL THE FEATURES!"
    "What about X?"
    "See let me explain why Git doesn't have X as if it's some kind of commandment from God and not simply the Git developers being incompetent, you see if you have a directed acyclic graph..."

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    Command-line can be used with both braille terminal and screen reader just fine.
    Or do you mean it figuratively?

    I can't use a CLI interface effectively. I can see.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    And that, precisely, breaks your argument. Because you now can't tell whether graphic designers prefer photoshop for its power or for its usability.

    Huh? You're gonna have to unwrap that one for me.

    Photoshop is better with regards to both power and usability, therefore you don't know if graphic designers prefer it for being more powerful or having a better UI, therefore Git...?

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    Given the similarity between programming and using CLI, programmers shouldn't be those people.

    Fuck you!

    Laying out Blueprints in Unreal is programming. Making Skyrim mods is programming. Creating workflows in SSIS is programming. None of those have even the slightest resemblance to using a CLI.

    Even if source control was only useful to programmers (it isn't-- it's just all products in the space are so painful to use nobody else bothers), your argument still doesn't hold up water unless you're going to insult thousands of people by telling them the programming they're doing "isn't actually programming" because they're No True Scotsman. In short, as one of those people: fuck you.

    Let me say this again as clearly as I can:

    There is not relationship between "programming" and "using a CLI"

    The guy making an address book mail merge app in Filemaker Pro is just as much a programmer as your snobby Linux-using ass.

    If Git's mission statement is "for programmers who still work like it's 1970 using tools that wouldn't look out of place in 1970", then maybe the shittiness of their product would be excusable. But if you're going to tell people it's for programmers, it has to be FOR programmers.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    Yes, I can imagine other types of users who would have trouble with it. But those are different use-cases, with different requirements. And Git is not suitable for them. And the maintainers never claimed it is. It was always marketed as software version control system.

    I write software and I think Git's a piece of shit. So I guess they're really bad at making a software version control system. Which is basically exactly what I've been saying all along.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    There is zero relation between whether it is an API and whether it is a DLL. Git has an API that involves invoking processes, sending them input and reading output.

    Then it doesn't work. If it did, we'd have quality UIs for Git. We do not. Demonstrably, what they're doing doesn't work.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    And most colleagues I knew and know still go to the command line for git. And they clearly don't have to, because the basic features are all accessible from the GUI and they could easily avoid the advanced ones. So the only explanation is that they actually find it easier once they get the grip of it.

    Good for them. I'm not trying to deprive them of anything. Even though they're probably idiots who are knee-jerking and haven't actually measured their efficiency in any objective way.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    Note: I am always talking about programmers and software project.

    ... but only programmers that do what you think programmers should do in your tiny little mind.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    Software companies tend to use it because programmers keep demanding it, not because the management would order it. Git does not have sales representatives to that would take the CTO to an opulent dinner and a night club, so CTOs don't have incentive to order it.

    And yet I'm fucking forced to use this piece of shit everywhere I go. It's like the universe just takes a big ol' smelly dump right on my head.



  • @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    These days most languages do have some kind of binding, usually via libffi. But once you want to pass more than primitive types, it gets tricky with memory ownership and packing the data and such and the end result is that it definitely isn't simpler than text-based IPC.

    I still don't feel like I (living here in 2017) should have to suffer because you idiots in the 1970s Linux world haven't figured out these basic problems yet.


  • FoxDev

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    Anyway, since they added git as the preferred version control component in TFS 2013

    What are you talking about? Git is simply one of two choices, the other being regular TFS. MS quite rightly recognises the two serve different requirements, and so gives you the choice of which to use.



  • @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    I've never heard of "pickaxe" and I think you made it up.

    Pickaxe is a search that will show all commits that either inserted or deleted a string from your codebase.

    It could be useful if you miss some function that was previously deleted from your program and want to recover it, for example.



  • @RaceProUK said in Big list of software that cannot handle spaces or accents in paths:

    @Gąska said in Big list of software that cannot handle spaces or accents in paths:

    @RaceProUK said in Big list of software that cannot handle spaces or accents in paths:

    @gwowen said in Big list of software that cannot handle spaces or accents in paths:

    As I explained very carefully earlier - they're writing this software for their needs (and more importantly their notion of usability).

    If they didn't intend for Git to be used outside of their little group, why is it available to the public?

    Why not?

    Because you don't release internal tools to the public.

    That's pretty unhelpful to people who could benefit from those internal tools. I doubt you're saying it's better for society as a whole if nobody ever released internal tools.


  • FoxDev

    @LB_ If you're going to release internal tools to the public, then you should at least make an effort to cater for people who may not operate the same way the originating group does.



  • @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    Good for them. I'm not trying to deprive them of anything.

    Yes, you are. You are claiming that it ‘is shit’ when it just ‘does not fit your needs’. It does not have to fit your needs. It clearly does fit the needs of majority. If it was as much shit as you claim, it is highly unlikely it would. But it does.

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    I write software and I think Git's a piece of shit.

    Yes, you think it is shit. Others don't. Therefore

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    So I guess they're really bad at making a software version control system.

    does not follow. They are pretty good at making software version control system. They've made a system that became popular. Without marketing. It became popular, because it did things users wanted, even if it often does it in idiosyncratic ways, which it does.

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    To me, it's just a pain in the ass that makes Git entirely unsuitable for a lot of my use-cases. Like putting Skyrim mods under source control.

    Then don't put Skyrim mods into Git. Choose something that is better fit. There are many version control systems. They make different trade-offs, so they have different sets of features. Some are mutually incompatible, so no system can actually have all of them. Git has many, and it covers use-cases of most programmers. You are not most and it does not cover yours. That still does not make it shit, just a wrong tool for your job.

    If anybody forces you to put Skyrim mods (or other things for which it is not suitable) into git, they may be idiots. That still does not make git authors idiots, because they don't claim git fits each and every use-case. They just claim it fits theirs and many other people thing it covers theirs as well. You are not many people, it may not cover yours.



  • @RaceProUK so if they just want to say "here's some source code, do with it what you will" you would say they shouldn't even bother in the first place? Why must there be a minimum bar to entry? Surely something is better than nothing.



  • @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    Without marketing.

    Bullshit.

    Without PAID marketing, ok, that I'll hand you.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    Git has many, and it covers use-cases of most programmers. You are not most and it does not cover yours. That still does not make it shit, just a wrong tool for your job.

    That's great, but the fact of the matter is I frequently get hired by companies that adopt it despite the fact that it doesn't fit their use-cases, and I'm useless to do anything about it.

    I'm not even talking about the usability/accessibility issues here (which, again, NOBODY should be defending). I'm talking about a company that absolutely needed to put binary files into their source control system and changes got stomped-over all the time because Git had no fucking file locking features that every other source control system had decades ago.

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    You are not many people, it may not cover yours.

    And yet I am subjected to it constantly, so maybe they should stop being assholes and make their product better?



  • @LB_ said in Big list of software that cannot handle spaces or accents in paths:

    Surely something is better than nothing.

    In this case, if they had delivered nothing, then I'd still be using Subversion of TFS and be relatively satisfied.

    So, yes, something is worse than nothing.


  • :belt_onion:

    @asdf said in Big list of software that cannot handle spaces or accents in paths:

    Even if you have an onion on your belt and prefer Eclipse, you'll have to admit that IntelliJ's Git UI is pretty awesome.

    The Visual Studio integration is pretty awesome in the later versions as well. Makes all the typical use cases as simple to handle as possible.


  • Grade A Premium Asshole

    @cark said in Big list of software that cannot handle spaces or accents in paths:

    @dkf Rebase. I do it like 20 times a day

    git reflog is gonna blow your goddamn mind. It's a history of everything you've ever done to your local repo from now until the last time git gc pruned old orphaned history. The default threshold for "old" is -I think- 14 days.

    So, if you fuck up a rebase and didn't think to tag/branch before you started the rebase, you can poke through the output of git reflog to get back to where you were before the error happened.


  • Winner of the 2016 Presidential Election

    @heterodox said in Big list of software that cannot handle spaces or accents in paths:

    Makes all the typical use cases as simple to handle as possible.

    It doesn't offer any of the advanced features, though.


  • Grade A Premium Asshole

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    I'm talking about a company that absolutely needed to put binary files into their source control system and changes got stomped-over all the time because Git had no fucking file locking features that every other source control system had decades ago.

    If a company stores data that needs to be stored in a relational database in MongoDB and later ends up with performance and data correctness problems because of their choice, does the fault lie with MongoDB for being asked to do what it cannot reasonably do, or with the people who used the wrong tool for the job?

    (Before you retort with a "MongoDB is just web-scale garbage!" read and try to comprehend the three data safety analyses of Mongo at jepsen.io http://jepsen.io/analyses .)



  • @Steve_The_Cynic said in Big list of software that cannot handle spaces or accents in paths:

    Depends on the boundaries of "normal usage of ToolX". If "p4 obliterate" is considered "normal usage", then you can do it with Perforce. Personally, I wouldn't call that particular command normal. Occasionally useful, but definitely not to be used even slightly often.

    And Perforce can be setup so normal users can't do that.



  • @bugmenot said in Big list of software that cannot handle spaces or accents in paths:

    does the fault lie with MongoDB for being asked to do what it cannot reasonably do, or with the people who used the wrong tool for the job?

    Yes.

    If your tool is the wrong tool for what a lot of its users are using it for, it's your responsibility (as a developer who isn't a shithead) to modify your tool to work as expected.

    Excel was being used for storing lists. Excel is designed to be a spreadsheet program, and had very few features designed to help people store lists. Microsoft added features to Excel to help those using it to store lists. They were happy. Microsoft made a lot more money. They were happy. Everybody was happy, except Lotus who kept 1-2-3 as a "pure" spreadsheet program.


  • :belt_onion:

    @asdf said in Big list of software that cannot handle spaces or accents in paths:

    It doesn't offer any of the advanced features, though.

    Hence why I said the typical use cases. It handles staging, committing, getting the history of files, seeing the difference between commits, merging, and rebasing. The typical developer isn't going to be doing anything more than that; that's why that's typically all that's handled through Web interfaces to Git as well.

    If we want to have pipe dreams of easy GUI access to advanced functionality, though, automated bisect would be pretty cool as VS has access to build the working copy obviously.


  • Banned

    @blakeyrat Microsoft didn't add lists-oriented features because people asked for it. They did it because people paid for it. I assure you if you paid Git developers enough money, they'd add all the features you want. But no one's paying them, so they don't care.



  • @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    And yet I am subjected to it constantly, so maybe they should stop being assholes and make their product better?

    That doesn't solve your problem of companies forcing shitty tools on us. I have much worse tools than git forced on me.


  • Grade A Premium Asshole

    @blakeyrat said in Big list of software that cannot handle spaces or accents in paths:

    If your tool is the wrong tool for what a lot of its users are using it for, it's your responsibility ...to modify your tool to work as expected.

    Oh. This is the time-honored Featureset-dictated-by-4chan Development Model! I remember that week in school. Our group project was to prove that every software ended up as a Turing-complete CP-spewing Photoshop clone that also functioned as a Tor exit node.

    Good times.


  • Impossible Mission - B

    It's been mentioned that Git was created by Linus Torvalds. The thing that no one has brought up so far is why, and it's very relevant to this discussion.

    As has been noted, a distributed VCS necessarily comes with certain losses of functionality. The question, then, is "why did Linus Torvalds need to create a distributed VCS?" And the answer is that he's running a massively distributed project, and you are not.

    It's exactly the same thing as NoSQL vs. SQL. It's pretty well-understood (around here at least) that the enormous projects run at Amazon and Google need web-scale databases to handle the unique engineering challenges faced by web-scale projects. (To truly understand the meaning of "web-scale," put "entire" in front of it: they're projects that (a significant fraction of) the entire Web uses.) The same is not true of the project you're working on, for 99.99+% of all values of "you", and so it's not worth losing the benefits of ACID in return for advantages you don't actually need.

    Well, that's what's going on with DVCS too. Unless you have a "web-scale" distributed development project, you do not need DVCS, and the benefits (which were designed for massively distributed projects) aren't worth the additional hassle it brings. Simply put, in almost every case, using DVCS is fundamentally :doing_it_wrong:.



  • @masonwheeler git is webscale, got it. So it means it must be very cool :p

    I'm forced to use SVN without merge tracking, because the powers that be dictated it. Git is much smarter on merging stuff.

    SVN suck.


  • Impossible Mission - B

    @wharrgarbl Why are you on an ancient version of SVN? The so-called "problems" with merging haven't existed for the better part of a decade now.



  • @masonwheeler Because the powers that be said merging inside svn is unreliable and we should avoid it.

    Not sure how well it works with branch to branch merges anyway. I don't really trust it either.


  • Grade A Premium Asshole

    @masonwheeler said in Big list of software that cannot handle spaces or accents in paths:

    Unless you have a "web-scale" distributed development project, you do not need DVCS, and the benefits (which were designed for massively distributed projects) aren't worth the additional hassle it brings.

    None of my projects will ever be "web-scale", and yet I use git as the VCS for all of them. I don't need to use it (in the same sense that I don't need to use an optimizing compiler), but I do. Why?

    • For almost every operation it's way faster than anything else out there.
    • It's way better at resolving complicated merges than SVN. (Yes, you rarely need this. But when you do need it, it saves a ton of time.)
    • If you're just using it as a "faster SVN", the set of commands to do this are not more complicated than the corresponding ones in SVN. (If you're going to object to this, be honest with yourself. If you came into SVN as a complete version control newbie, there was a significant period of ":wtf: Who the hell would name this command that, and why do you have to pass these stupid flags to get it to do the right thing? Why can't this shit be simple?".
    • Because you can alter history at will, git encourages more frequent mid-development checkpoint commits. My brain is small, so I find that I need a bunch of checkpoints to fall back on when I inevitably break something that used to work. Because I don't have to actually publish these (often half-baked) commits, I actually make the checkpoints that I need to work effectively.

    If I regularly worked on huge repos, I'd miss SVN's sparse checkouts (though there's a actually a multi-step method to do just this that's begging to have some porcelain laid on top of it). If I regularly worked with files that were dreadfully difficult to merge, I'd miss file locking (though gitolite and other git servers offer file locking mechanisms with syntax no weirder than SVN's that is amenable to having some trivial porcelain laid on top of it).



  • @masonwheeler It also seems like a good fit for other open source projects, where a possibly infinite number of forks is likely, but you want the ability to merge upward in case that ever becomes a good idea.

    But in our case, where I work, it makes no sense for us to use git: there's only one ultimate version of the truth, and using it has caused more headaches than advantages, especially when it randomly gets confused about things that TFS has handled consistently for us for years.

    But this is what was mandated for this new project, so we're stuck with it.


  • :belt_onion:

    @RaceProUK said in Big list of software that cannot handle spaces or accents in paths:

    In other words, they're more interested in shiny and their own needs than usability and the needs of others.

    That's how/why software like Linux and Git came to exist on the first place.

    Unlike Windows, Office, OSX, Photoshop, etc., they were created to fit the specific needs of a small group of people, with no thought of anyone outside that group, and they became popular entirely by accident.



  • @dcon said in Big list of software that cannot handle spaces or accents in paths:

    @Steve_The_Cynic said in Big list of software that cannot handle spaces or accents in paths:

    Depends on the boundaries of "normal usage of ToolX". If "p4 obliterate" is considered "normal usage", then you can do it with Perforce. Personally, I wouldn't call that particular command normal. Occasionally useful, but definitely not to be used even slightly often.

    And Perforce can be setup so normal users can't do that.

    Yeah, that, too. My Perforce depot at home has 17 years of commits in it, and when I back it up (stop server, run tar czvf $TARFILE, start server), the output is nearly 10 GB. I have occasional need to run p4 obliterate but that "17 years" thing means I'm just a teeny tiny bit careful with it.


  • Discourse touched me in a no-no place

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    Eclipse can also do everything with Git it can do with Subversion and TFS.

    FWIW, Eclipse can do quite a bit more with Git than it can do with Subversion. Its integration is good enough that I only need the command line when doing tricky stuff like squashing across merge commits, migrating repositories (not your everyday activity) or doing deep rewrites of history (very much not a common case for any VCS). However, I find it tremendously useful to have some of the specialist views enabled.

    Other IDEs might be good in this area too. I don't know them. :) Except I don't like anything by JetBrains, IntelliJ irritated me massively a long time ago and I've ignored it for a long time, and Friends Don't Let Friends Use Xcode.



  • @dkf said in Big list of software that cannot handle spaces or accents in paths:

    FWIW, Eclipse can do quite a bit more with Git than it can do with Subversion.

    I am pretty sure it does. But for the argument, not doing less was enough.

    @dkf said in Big list of software that cannot handle spaces or accents in paths:

    Other IDEs might be good in this area too. I don't know them.

    While I don't use Eclipse.

    @dkf said in Big list of software that cannot handle spaces or accents in paths:

    Except I don't like anything by JetBrains

    For me it would be really good if it was not so flakey. Resharper C++ is great, but occasionally breaks down and takes Visual Studio with it. WebStorm mostly works for code navigation, but I couldn't really get either JavaScript Debugging (via the Chrome plugin) nor Chrome remote debugging, to work. And debugging in AndroidStudio somehow broke down on all our Pixel C tablets (that are otherwise the best we have), which is poor score given it is the only thing I can use it for given the ❄ build process.

    The worst thing about it is having to juggle 3 IDEs in the course of normal work.

    @dkf said in Big list of software that cannot handle spaces or accents in paths:

    Friends Don't Let Friends Use Xcode.

    QFT.

    We have a MacBook in each office so we can add files to the XCode projects. Everybody hates them.


  • Discourse touched me in a no-no place

    @Bulb said in Big list of software that cannot handle spaces or accents in paths:

    And that only covers one side. How do you wrap a python function in a DLL? A perl one? A Java one? A Shell one? That direction is just as important.

    Generally speaking, the big complications there relate to runtime libraries — virtually all languages have them, and some are very intrusive (and even the JVM and CLR are not the worst in this respect; Oberon, some Lisps and HolyC take that to another level) — with a side-trip into binding layer generation (though that's not too awful to solve provided you don't mind the runtime cost). The big advantage that languages targeting a platform like the CLR or JVM have is that they're using essentially a single basic runtime when those languages are used from another language on the same platform; life gets very awkward from outside.


Log in to reply