How hard is Git integration? Can Spambots do it?


  • BINNED

    It must be the NSAs!


  • Winner of the 2016 Presidential Election

    I wouldn't be surprised if @wood ends up blaming one of us.


  • BINNED

    Don't bots use a specific UA string? @accalia / @RaceProUK?

    Also, is there logged anyway?



  • @asdf said:

    CMD was finally made usable

    Lies!


  • FoxDev

    SockBot-based bots use their own UA string that identifies them as a SockBot; they also tag each post with an HTML comment saying the same.

    Other bots... who knows?


  • BINNED

    I know about the tags. I'm asking because if someone is using their code they might have forgotten to change the UA bit since it's not as noticeable.

    Yeah, I know, not likely, but hey...



  • @Onyx said:

    I'm asking because if someone is using their code they might have forgotten to change the UA bit since it's not as noticeable.

    Frankly, I'm betting on a mechanical Turk, especially given the delays between the posts and the linkifying using the toolbar syntax...


  • FoxDev

    @Onyx said:

    Don't bots use a specific UA string?

    yes, yes they do

    https://github.com/SockDrawer/SockBot/blob/master/lib/browser.js#L21-L22

    @Onyx said:

    Also, is there logged anyway?
    not in discourse, but nginx logs it in access log.


  • BINNED

    @accalia said:

    not in discourse

    Frell.

    @accalia said:

    but nginx logs it in access log

    Yeah, I know, but I don't think we can access that.


  • FoxDev

    This post is deleted!

  • FoxDev

    @Onyx said:

    Yeah, I know, but I don't think we can access that.

    no, but if you ask nicely @PJH can.<a

    if you bribe him with alcohol he'll probably extract the logs for your nefarious porpoises too.


  • BINNED

    @accalia said:

    your nefarious porpoises

    Hey! That's slander right there!

    My porpoises are just a tad mischievous at times, nothing more.


  • Discourse touched me in a no-no place

    root@what:/# grep Cindy /var/log/nginx/access.log | grep POST | grep /posts
    [19/Jan/2016:09:12:28 +0000] 36.79.233.172 "POST /posts HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "posts/create" 200 2147 "https://what.thedailywtf.com/t/enlightened/8795/730" 3.308 3.308 "Cindy_Adelia"
    [19/Jan/2016:09:14:10 +0000] 36.79.233.172 "POST /posts HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "posts/create" 200 2236 "https://what.thedailywtf.com/t/enlightened/8795/731" 2.848 2.848 "Cindy_Adelia"
    [19/Jan/2016:09:15:17 +0000] 36.79.233.172 "POST /posts HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "posts/create" 200 2234 "https://what.thedailywtf.com/t/enlightened/8795/731" 2.473 2.473 "Cindy_Adelia"
    [19/Jan/2016:09:15:45 +0000] 36.79.233.172 "POST /posts HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "posts/create" 422 1686 "https://what.thedailywtf.com/t/enlightened/8795/732" 2.897 2.897 "Cindy_Adelia"
    [19/Jan/2016:09:17:30 +0000] 36.79.233.172 "POST /posts HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "posts/create" 200 2167 "https://what.thedailywtf.com/t/how-hard-is-git-integration/54051" 5.131 5.131 "Cindy_Adelia"
    [19/Jan/2016:09:18:03 +0000] 36.79.233.172 "POST /posts HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "posts/create" 200 2299 "https://what.thedailywtf.com/t/how-hard-is-git-integration/54051/44" 1.598 1.598 "Cindy_Adelia"
    [19/Jan/2016:09:19:07 +0000] 36.79.233.172 "POST /posts HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "posts/create" 200 2215 "https://what.thedailywtf.com/t/how-hard-is-git-integration/54051/46" 3.663 3.663 "Cindy_Adelia"
    root@what:/# 
    

    Given the timings, that doesn't look like a bot to me.



  • HTTP 422? What's that?


  • Discourse touched me in a no-no place

    @aliceif said:

    HTTP 422? What's that?

    Yes.


  • Discourse touched me in a no-no place

    Seems to be a repurposed code:

    **422 Unprocessable Entity (WebDAV; RFC 4918)** The request was well-formed but was unable to be followed due to semantic errors.[17]

  • FoxDev

    Well, they had to use something I guess; not like there's a code for too many requests...


  • BINNED

    That's reserved for clicking the ❤ button too fast.


  • Discourse touched me in a no-no place

    @RaceProUK said:

    Well, they had to use something I guess; not like there's a code for too many requests...

    But there wasn't - at least not that I'd consider it too many:

    root@what:/# grep 36.79.233.172 /var/log/nginx/access.log | grep  "\"posts/create\" 422 1686 " -B10 
    [19/Jan/2016:09:15:19 +0000] 36.79.233.172 "POST /message-bus/a349f35d291b4e5ea83614ec57e948a4/poll? HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "-" 200 397 "https://what.thedailywtf.com/t/enlightened/8795/732" 0.177 0.177 "-"
    [19/Jan/2016:09:15:19 +0000] 36.79.233.172 "GET /composer-messages?composerAction=reply&topic_id=8795&_=1453194805485 HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "composer_messages/index" 200 1755 "https://what.thedailywtf.com/t/enlightened/8795/732" 1.082 1.082 "Cindy_Adelia"
    [19/Jan/2016:09:15:27 +0000] 36.79.233.172 "POST /draft.json HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "draft/update" 200 1676 "https://what.thedailywtf.com/t/enlightened/8795/732" 0.056 0.056 "Cindy_Adelia"
    [19/Jan/2016:09:15:36 +0000] 36.79.233.172 "POST /message-bus/a349f35d291b4e5ea83614ec57e948a4/poll? HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "-" 200 496 "https://what.thedailywtf.com/t/enlightened/8795/732" 16.133 16.133 "-"
    [19/Jan/2016:09:15:37 +0000] 36.79.233.172 "POST /topics/timings HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "topics/timings" 200 1515 "https://what.thedailywtf.com/t/enlightened/8795/732" 0.679 0.679 "Cindy_Adelia"
    [19/Jan/2016:09:15:40 +0000] 36.79.233.172 "POST /message-bus/a349f35d291b4e5ea83614ec57e948a4/poll? HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "-" 200 497 "https://what.thedailywtf.com/t/enlightened/8795/732" 3.878 3.878 "-"
    [19/Jan/2016:09:15:41 +0000] 36.79.233.172 "POST /draft.json HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "draft/update" 200 1562 "https://what.thedailywtf.com/t/enlightened/8795/732" 0.063 0.063 "Cindy_Adelia"
    [19/Jan/2016:09:15:42 +0000] 36.79.233.172 "POST /message-bus/a349f35d291b4e5ea83614ec57e948a4/poll? HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "-" 499 0 "https://what.thedailywtf.com/t/enlightened/8795/732" - 1.392 "-"
    [19/Jan/2016:09:15:43 +0000] 36.79.233.172 "POST /message-bus/a349f35d291b4e5ea83614ec57e948a4/poll? HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "-" 200 553 "https://what.thedailywtf.com/t/enlightened/8795/732" 1.176 1.176 "-"
    [19/Jan/2016:09:15:43 +0000] 36.79.233.172 "POST /topics/timings HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "topics/timings" 200 1513 "https://what.thedailywtf.com/t/enlightened/8795/732" 0.408 0.408 "Cindy_Adelia"
    [19/Jan/2016:09:15:45 +0000] 36.79.233.172 "POST /posts HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" "posts/create" 422 1686 "https://what.thedailywtf.com/t/enlightened/8795/732" 2.897 2.897 "Cindy_Adelia"
    root@what:/# 
    
    


  • Shut the fuck up about the spam, we're talking about Git.

    Oh fuck it, another thread ruined by talking about shitty ass stupid bots made by morons.


  • BINNED

    @blakeyrat said:

    Shut the fuck up about the spam, we're talking about Git.

    Ok. I like it.

    @blakeyrat said:

    Oh fuck it, another thread ruined by talking about shitty ass stupid bots made by morons.

    No, we're done now that we established there were no bots, it was just a human spammer. Which is now gone. Carry on.



  • @hifi said:

    It's different to bitch about broken implementations than bitch Git is shit because of broken implementations.

    If software is shitty at doing X, then it's shitty software. I don't understand the confusion there.

    @hifi said:

    The difference is I'm competent to use Git from the CLI and I complain when GUI tools can't even remotely do the same things as the CLI, like a damn repository clone.

    It's not competence that's the problem, it's ability.

    @hifi said:

    Not like Torvalds forced everyone else to use Git in the first place (except the kernel developers).

    True; but it is his fault that Git is such a shitty piece of software. For example, it's entirely his fault that there's no API for Git, so third-parties have to use the CLI interface as an ad-hoc API.

    @hifi said:

    It's a convenience to have source control integrated to an IDE, not its purpose.

    I could not disagree with you more.

    @hifi said:

    It's a well known fact all Git integrations suck one way or another and I'm with you 100%.

    Right; and if Git weren't shitty, they'd probably work a lot better. Or at least have a fighting chance.

    So look, here's a partial list of companies/organizations that have failed to come up with a competent Git integration:

    • Microsoft
    • Atlassian
    • Xamarian
    • GitHub

    How is it possible ALL those organizations have failed at it? The answer could only be: Git sucks and is badly-designed.

    @hifi said:

    You usually pull the card that Git itself (the CLI) is somehow broken

    The entire concept of using a CLI as an API is broken and wrong.

    @hifi said:

    and I disagree with that as it has never done anything unexplainable for me

    I find that extraordinarily hard to believe.

    @hifi said:

    and you have failed to give any good examples where the CLI would be broken and not work like it's supposed to.

    Because that's not the point. I've explained the usability problems around a piece of software ONLY being available in CLI form about 347,242 times on this forum, I'm not going to do it again.

    Of course if you actually can tolerate Git, you probably have no shits to give about software actually being usable. You're in the lovely open source "got mine, fuck everybody else" mindset that's the same mental defectiveness that led Torvalds to release this broken crap in the first place.

    @hifi said:

    I was calling out Xamaramammran because their integration is also bad

    Of course it's bad. Because Git is bad. You're blaming the wrong party here.

    There's two parties involved in the integration. The only thing in common among all the various companies that have failed at it is Git.



  • @Onyx said:

    No, we're done now that we established there were no bots, it was just a human spammer. Which is now gone. Carry on.

    Hey, here's a thought: don't shit all over the thread in the first fucking place.



  • @blakeyrat said:

    If software is shitty at doing X, then it's shitty software. I don't understand the confusion there.

    Git as a general concept isn't shitty software, it's a sound and working concept. Unofficial implementations and integrations can be and usually are just that - shitty software.

    @blakeyrat said:

    True; but it is his fault that Git is such a shitty piece of software. For example, it's entirely his fault that there's no API for Git, so third-parties have to use the CLI interface as an ad-hoc API.

    It's not his fault that people abuse the CLI as an API. Seriously. If I try to drive a regular car into a lake and complain it doesn't float it's not the car manufacturers fault when the description said "can drive on regular road".

    Your argument is that all cars must be amphibious because you have an opinion that they must.

    @blakeyrat said:

    @hifi said:
    It's a well known fact all Git integrations suck one way or another and I'm with you 100%.

    Right; and if Git weren't shitty, they'd probably work a lot better. Or at least have a fighting chance.

    So look, here's a partial list of companies/organizations that have failed to come up with a competent Git integration:

    • Microsoft
    • Atlassian
    • Xamarian
    • GitHub

    How is it possible ALL those organizations have failed at it? The answer could only be: Git sucks and is badly-designed.

    • Microsoft - just added Git support through libgit2 (👍) , still incomplete
    • Atlassian - :doing_it_wrong:
    • Xamarian - not enough experience because it's too broken to clone a repo
    • GitHub - :doing_it_wrong:

    @blakeyrat said:

    @hifi said:
    You usually pull the card that Git itself (the CLI) is somehow broken

    The entire concept of using a CLI as an API is broken and wrong.

    And this has what to do with Git itself that's a CLI application and is used as such unless :doing_it_wrong:?

    @blakeyrat said:

    @hifi said:
    and I disagree with that as it has never done anything unexplainable for me

    I find that extraordinarily hard to believe.

    Because you don't use the CLI.

    @blakeyrat said:

    Because that's not the point. I've explained the usability problems around a piece of software ONLY being available in CLI form about 347,242 times on this forum, I'm not going to do it again.

    And that's entirely your problem if you can't use a keyboard.

    @blakeyrat said:

    Of course if you actually can tolerate Git, you probably have no shits to give about software actually being usable. You're in the lovely open source "got mine, fuck everybody else" mindset that's the same mental defectiveness that led Torvalds to release this broken crap in the first place.

    Yes, I can tolerate Git, that's right. I also tolerate a lot of other software what are good at what they do even when they don't have the best user experience.

    I do care about user friendliness when it comes to something I create. I've already agreed that the Git CLI isn't intuitive or discoverable but it's learnable through other means and once you learn how to type X you don't forget it in the next 5 seconds, unless you're a goldfish and we've already discussed that goldfish shouldn't be doing computing because you need to remember shit.

    I can tell you million things wrong with open source, I complain about open source software every single day. It's a really rare occurance when open source software is top notch. But please at least complain about the IDE or a broken CLI wrapper GUI rather than Git - the software - when they are the ones at fault.



  • @hifi said:

    Git as a general concept isn't shitty software, it's a sound and working concept.

    But Git AS A PIECE OF SOFTWARE is poorly-designed and shitty. We're not using the concept; we're using the software.

    (Even as a concept, it's pretty feature-bare compared to its competitors. It can't handle sparse repos, or checking-out only subdirectories, it can't handle file locking or anything equivalent, it can't store stashes on the server, etc. So I actually take issue with your original statement. But we'll skip that for now.)

    @hifi said:

    Unofficial implementations and integrations can be and usually are just that - shitty software.

    If Git were well-designed, it'd be easy to integrate with.

    @hifi said:

    It's not his fault that people abuse the CLI as an API.

    Apparently it is. According to Gaska, he doesn't provide an API at all. So companies like Xamarin and Microsoft who want to do the logical common thing with a source control product (integrate it with their IDE) are fucked.

    So yes, it is his fault. (Or his team's fault, I don't know how personally involved he is.)

    @hifi said:

    Seriously. If I try to drive a regular car into a lake and complain it doesn't float it's not the car manufacturers fault when the description said "can drive on regular road".

    But we're not talking about a car that doesn't float.

    We're talking about a car that works fine on city streets, but the wheels fall off 10 seconds after you put it on the freeway.

    @hifi said:

    Your argument is that all cars must be amphibious because you have an opinion that they must.

    No.

    Integrating a source control product into an IDE is the common, usual thing to do. Like driving a car on the freeway.

    @hifi said:

    And this has what to do with Git itself that's a CLI application and is used as such unless :doing_it_wrong:?

    Look. Application != UI.

    Welcome to programming 101. Your application should be implemented separately from it's user interfaces. A lesson known by everybody except really shitty open source developers for decades.

    If Git were written correctly, all of its core functionality would be in the form of a DLL that anybody else could link to and use. And it's CLI would be a different application altogether. That's the way software written by non-morons works. Now Git's free to change the CLI whenever they want. And third-party applications can use the DLL's functions to do what they need without ever having to worry about creating a virtual console or trying to parse human-readable (or not, in Git's case) error messages.

    It's just plain GOOD SOFTWARE ENGINEERING. Which is, of course, why Git doesn't do it: Git's designed by an incompetent programmer, and maintained by incompetent programmers.

    @hifi said:

    Because you don't use the CLI.

    And therefore...?

    @hifi said:

    And that's entirely your problem if you can't use a keyboard.

    Oh great. The open source ethos: you're disabled? FUCK YOU! RAM A RED HOT POKER UP YOUR ASSHOLE DISABLED PERSON! YOU ARE HUMAN TRASH! YOU ARE NOT ALLOWED TO USE OUR SOFTWARE BUILT FOR NORMYS!

    This is the philosophy you're going with. Seriously. Think about what you're saying. Do you go to the local mall with a jackhammer and tear up the handicapped ramps too?

    If this is actually what you believe instead of you just being a moron and barfing out shit you haven't actually thought about, then fuck you.

    @hifi said:

    Yes, I can tolerate Git, that's right.

    That's fine; as long as you don't tell people it's good software.

    I don't care if you use it. I don't even care if you like it. I care that idiots like you are going around telling people that Git is good software when it's not.

    Earlier you said it wasn't Torvald's fault that companies like mine adopted Git. Ok. Fine. But who's fault is it, then? SHITHEADS LIKE YOU! Lying about it being good software when it's obvious at the most casual glance that it is not.

    @hifi said:

    I've already agreed that the Git CLI isn't intuitive or discoverable

    This is what bothers me the most. YOU KNOW IT'S SHITTY. So why do you keep defending it? Software that isn't intuitive or discoverable is BAD SOFTWARE.

    @hifi said:

    but it's learnable through other means and once you learn how to type X you don't forget it in the next 5 seconds,

    That doesn't help the guy with Dyslexia. His memory isn't the problem.

    That said, most people have a weak rote memory. If Git weren't shitty, it'd have a GUI that made use of spatial memory, which is very strong in most people. That would make it a hundred times easier to use, especially among people who haven't spend a lifetime in CLIs building-up their rote memory.

    @hifi said:

    But please at least complain about the IDE or a broken CLI wrapper GUI rather than Git - the software - when they are the ones at fault.

    But Git is the software they're trying to integrate WITH, you idiot. How else can I explain this?

    Look, Git doesn't provide the API it needs to to make quality integrations possible. That makes it Git's fault that there are no quality integrations. It's so simply. I honestly have no idea how you're not absorbing this information.

    EDIT, BTW:

    @hifi said:

    I do care about user friendliness when it comes to something I create.

    You liar.

    A few paragraphs previous you were all like, "if you can't use a keyboard, FUCK YOU!" Now you're claiming you care about user friendliness? "if you can't use a keyboard, FUCK YOU" is your idea of user friendliness?



  • Actually, Git apparently does have an API... but it's an internal C API and not an .so/.dll.



  • @powerlord said:

    Actually, Git apparently does have an API... but it's an internal C API and not an .so/.dll.

    Oh awesome. So not only did they do everything stupid and wrong, but they did it stupid and wrong for pretty much no reason. I guess because they were too fucking lazy to shove the API bits into a different project.



  • @hifi said:

    Because you don't use the official Git client which is the CLI. For the millionth time, stop using broken integrations and learn the damn tool.

    Far be it from me to defend Blakeyrat's trolling, but he's got a point about Git, and you're horrendously wrong here.

    A CLI is not a user interface. That broken paradigm has been technically obsolete since 1984 when Apple presented the Macintosh to the world, and officially obsolete since 1995 when Microsoft popularized Apple's work by mass-marketing their own version of it. Command lines are a text-based interface that are highly useful for scripting, but if you present it to an end-user, you are Doing It Wrong. If your product, be it an operating system or a piece of user software, requires the end-user to know that a command line exists, you are Doing It Wrong!

    The willful refusal of the Linux community to understand this is quite possibly the most significant reason why it never gained any non-trivial level of market share outside server-land until Google came out with Android, one of the distinguishing characteristics of which is that is has no CLI shell whatsoever.

    @blakeyrat said:

    Once again: it's a source control tool. The entire PURPOSE of those are to integrate with other programs.

    Where do you get this idea that source control is supposed to integrate with an IDE? I've seen various IDEs attempt to get this right with various different VCSs, and they invariably fail miserably for one reason or another. What does tend to work well is source control integration with Windows Explorer. But regardless, the "entire purpose" of source control has nothing to do with integration with anything.

    Source control has two purposes. 1) Making a versioned backup of your work, and 2) allowing multiple developers to integrate their work into a single versioned backup system with a minimum of hassle. Neither of these have anything to do with the implementation detail of "integrating with IDEs."

    @hifi said:

    Git as a general concept isn't shitty software, it's a sound and working concept.

    Nope. It's based on a fundamentally broken concept: DVCS.

    Version control is all about making a shareable versioned backup of your work. DVCS ignores this important principle and introduces the broken concept of an all-important "local repository," which turns everything inside out. A local repository is not version control, because it doesn't function as a backup: if your hard drive dies, the local repo goes down with the ship and you've lost your work.

    The two most important, most fundamental operations in source control, the two that will be used the most often by every developer using it, are the operations of sending changes to the repository and copying changes from it. They have various names; let's just call them Push and Pull here for simplicity. In a properly designed VCS, such as SVN, the Push and Pull actions are simple to perform. Push is a single operation: you select what changes to commit, write a commit message, and it sends. (Unless of course the server determines that your Push would potentially cause a merge conflict, in which case it requires you to Pull first and then repeat your Push. A well-designed client will handle this for you.) And that's all there is to it.

    In a DVCS, there is nothing simple about a Push. It starts simple enough: you select the changes to send, write a commit message, and perform the commit operation. But this doesn't actually check in your changes; it copies them to the local repo. You then have to take a second step to Push your changes. But if someone else has made changes on your branch, even if none of the files they touched are the same as the files you're checking in changes to, the server screams "CONFLICT!" at you and you have to Pull and integrate first. (But for some reason DVCS proponents like to claim that DVCS is better at merging?) For extra fun, try asking Mercurial to show you the set of your local commits that will be pushed to the server. It has to contact the server to determine this! In what world does that make any sense whatsoever?

    In a properly designed VCS, such as SVN, Pull is a single operation. You tell it to fetch changes from the server, and it grabs everything from your branch and integrates it automatically. If someone has changed the same lines as you, you get a merge conflict that you have to resolve manually, but these are rare. (Unless your project management is incompetent or your codebase is a mess, either of which could easily be true.) And then you're good to go.

    In a DVCS, Pull is horrendously overcomplicated. First you pull changes from the server, which go into your local repo. This takes much longer than SVN, because it pulls every change from every branch, including all the ones you aren't working on and don't care about. Then, even under ideal circumsntances, where none of the files that have changed on your branch are any different from the ones you have local changes to, it still doesn't update your working copy, which is the entire point of running a Pull operation, so you have to manually update to the head. (The GitHub for Windows client tries to combine these operations, but it has its own nasty quirks when things are less than ideal, under "conflict" circumstances SVN wouldn't even blink an eye at.) But if any of the files you've changed locally are the same as the files that have changed from the other branch, even if they're in completely different parts of the file, your DVCS will freak out at this and tell you you're going to get conflicts everywhere. HG has a way to force the merge and tell it to do its best to do what SVN does naturally: just integrate the changes, but bogus merge conflicts are annoyingly common. Git, as far as I know, does not have a way to force the merge; you have to shelve your changes, update your working copy, and then un-shelve. (But for some reason DVCS proponents like to claim that DVCS is better at merging?!? DVCS is positively terrified of merging, like the proverbial elephant in the presence of a mouse!)

    All this "local repo" idiocy is there to support the D in DVCS: "Distributed." Distributed version control is like NoSQL: it's very useful for projects that are much larger and more complex than the one you're working on, but at more realistic scales it gets in the way. The poster child for the paradigm is the Linux kernel; Git was literally created to help out with its development. But how many projects look like the Linux kernel from a project management perspective? The one you're working on isn't massively decentralized with thousands of developers around the world working on hundreds of somewhat-independent forks, is it?

    It's quite fitting that the two most common DVCS systems have names that mean "idiot" and "temperamental". Anyone using them needs look no further than the name to know what they're getting themselves into when they start using it.

    @blakeyrat said:

    Welcome to programming 101. Your application should be implemented separately from it's user interfaces. A lesson known by everybody except really shitty open source developers for decades.

    Really? This guy has the opposite perspective: Open-source projects are the ones that keep adhering to that principle the most strictly, and it's directly responsible for open-source projects frequently having lousy usability:

    [Eric S.] Raymond writes as though they’re almost there, but just need, you know, the finishing touches. The extra yard. The cherry on top. The pièce de résistance. I.e., We’ve got the hard part done — the under-the-hood foundation — now we just need a better UI and we’ll be set.

    But this is not a radical new direction for open source desktop software. What Raymond is proposing, in fact, is no change at all. This idea, that the hard work of development is in building the underlying foundation, and that the easy part is writing a “GUI wrapper”, has been the Linux/Unix way all along.

    Raymond’s proposal is predicated on the idea that good UI design and development is easy, that developers simply need to keep [non-technical users] in mind and the design will fall into place.

    Well, allow me to retort.

    UI development is the hard part. And it’s not the last step, it’s the first step. In my estimation, the difference between:

    • software that performs function X; and
    • software that performs function X, with an intuitive well-designed user interface

    isn’t just a little bit of extra work. It’s not even twice the work. It’s an entire order of magnitude more work. Developing software with a good UI requires both aptitude and a lot of hard work.

    He follows up on this:

    1. The user interface — the entire user experience — should be designed first, and the underlying implementation should be built to support the design.
    2. Thus, the traditional Unix/Linux development model, wherein back-end implementations are written first, and GUI “wrappers” are written around them later, is completely backwards.

  • ♿ (Parody)

    @Mason_Wheeler said:

    Far be it from me to defend Blakeyrat's trolling, but he's got a point about Git, and you're horrendously wrong here.

    A CLI is not a user interface.

    That's not his point. Blakey's point is that a CLI is not an API. I don't fully agree with him, but I get his point. You're making a different point.


  • I survived the hour long Uno hand

    @Mason_Wheeler said:

    Really

    @blakeyrat said:

    Your application should be implemented separately from it's user interfaces

    Is not the same statement as

    @Eric S said:

    the hard work of development is in building the underlying foundation, and [...] the easy part is writing a “GUI wrapper”,

    They should absolutely be written separately: the GUI layer by GUI experts who, using a mocked-up backend, run usability trials before they settle on a final design, while the logic is written by developers who don't know or care about usability.



  • @Yamikuronue said:

    They should absolutely be written separately: the GUI layer by GUI experts who, using a mocked-up backend, run usability trials before they settle on a final design, while the logic is written by developers who don't know or care about usability.

    They should care about usability, but usability of the API is not the same as usability of the GUI. Both should be designed with their final users in mind, APIs for programmers and GUIs for general users.

    An API that can only be used by a single interface is of no use, and that's what you get when you build the API to support the interface.


  • I survived the hour long Uno hand

    @Sentenryu said:

    that's what you get when you build the API to support the interface.

    Right. So build them separately.


  • :belt_onion:

    Blakey keeps talking about a Git library...

    Like this one?



  • @Mason_Wheeler said:

    A CLI is not a user interface.

    Thank you for your support, but a CLI is by definition a user interface. It's just a really shitty one that a lot of people are incapable of using for various reasons.

    @Mason_Wheeler said:

    Command lines are a text-based interface that are highly useful for scripting, but if you present it to an end-user, you are Doing It Wrong. If your product, be it an operating system or a piece of user software, requires the end-user to know that a command line exists, you are Doing It Wrong!

    Moreover, if you aren't willing or able to create a proper GUI application for your program, you could at the very least provide a proper API so other people can. That would be the bare minimum for me to call Git non-shitty.

    @Mason_Wheeler said:

    Where do you get this idea that source control is supposed to integrate with an IDE?

    It's obvious. Where do you get the idea that source control isn't?

    You know why I still use Visual Studio to do merges instead of SourceTree? Part of it is that VS isn't as shitty in general, but a vastly more important part is that VS understands C# and XML syntax and thus is a million times better at merging C# and XML changes. SourceTree will tell me there's 200 conflicts, by the time VS is done with it there's 2.

    @Mason_Wheeler said:

    What does tend to work well is source control integration with Windows Explorer.

    Windows Explorer doesn't know:

    1. The syntax of the language when making merges
    2. Which changed files should belong in the repo and which should not (easy for an IDE to determine this)
    3. When there are changed files that should be added to the commit
    4. Requires you to open the project/solution folder in Explorer to work with (not a big deal, but not something I do when working with an IDE)

    etc.

    Integrating source control with Explorer isn't a terrible idea, but it's still inferior to integration with the IDE.

    There's also the whole philosophy of the IDE as a one-stop shop for all your programming tools. The I stands for "Integrated". The whole point is that your editor, compiler, debugger, profiler, etc. are all there in one place, and since they're all working together you get a significantly better experience than working with each component independently. For example, with a single click on a line of code I can flag it as a breakpoint for my debugger. And that's the most simple example I can think of. Imagine trying to work with a debugger you have to manually tell about breakpoints every goddamned time you run it, your productivity would sink like a stone.

    @Mason_Wheeler said:

    Really? This guy has the opposite perspective: Open-source projects are the ones that keep adhering to that principle the most strictly, and it's directly responsible for open-source projects frequently having lousy usability:

    I agree with that somewhat, but the FIRST STEP in usability is separating the interface from the application. Especially in an open source world where you'd fully expect (due to "freedom") that people would want to pick their own GUI for the application. (Hell, the flagship open source OS even lets you pick your own GUI! KDE, Gnome, Unity, your choice! This is possible because X11 is the library that enables it. X11 is shitty, but it has the right idea.)

    In the case of Git, it's unthinkable that the developers in charge of it would ever give even half a shit towards usability. But what they could do to throw us a bone is to give Git a complete API so other people who do care about usability can help!

    In a monolithic application where there's no difference between the application and the UI to the application, there's no chance. You haven't even reached the starting line of creating a usable application.

    We're talking about what it would take to make Git even slightly usable in a GUI. If we had a time machine, and a clue-bat to generously apply to Torvalds' head, then yes, I'd have given him Gruber's essay before he wrote even a single line of code. But we don't.

    I just want to be able to use my fucking computer day-to-day without pulling out my hair in frustration.



  • @sloosecannon said:

    Blakey keeps talking about a Git library...

    Like this one?

    As we've discussed, that library is:

    1. An afterthought, not a core part of the Git product
    2. Incomplete

  • :belt_onion:

    @blakeyrat said:

    a core part of the Git product

    Of course not, the core part of the Git product is a CLI.

    @blakeyrat said:

    Incomplete

    How?



  • @sloosecannon said:

    How?

    Scroll up and ask whoever made that claim, I'm not your "read the thread slave".


  • :belt_onion:

    ENOTFOUND

    I found several people talking about how people should be using libgit2 but nobody talking about it being incomplete. Nothing I can see from their website or a quick overview of Github, nor from a quick Google search indicates that libgit2 is in any way less feature-complete than Git proper. So I'm gonna mark that one as an ass-pull.



  • @sloosecannon said:

    I found several people talking about how people should be using libgit2 but nobody talking about it being incomplete

    I found one quite easily.

    @Gaska said:

    Except libgit2 is inferior to actual Git in at least one way - it doesn't support shallow clones


  • :belt_onion:

    Eh, blame Discosearch.

    Still, that's one feature, and it's a feature that (IIRC) makes the repository almost impossible to work with anyways. So... meh.



  • @Yamikuronue said:

    They should absolutely be written separately: the GUI layer by GUI experts who, using a mocked-up backend, run usability trials before they settle on a final design, while the logic is written by developers who don't know or care about usability.

    If you think that the UI is a "layer", as something that should exist independent of "the logic" and be "decoupled" from it, you're already missing the point: the interface is the application. Every single bit of functionality anywhere in "the logic" has only one purpose: to service requests made from the interface. (Note for the pedantic: this is not necessarily the user interface. There are other ways to interface with a program, and many programs incorporate more than one variety. The point still stands.) Any "logic" code that can't be activated from the interface is unreachable; it is functionally dead code even if the compiler can't detect it as such. If the developers don't know or care about usability, then you're going to end up with a schizophrenic product at best.

    @blakeyrat said:

    Thank you for your support, but a CLI is by definition a user interface. It's just a really shitty one that a lot of people are incapable of using for various reasons.

    That's a very poor definition, and has been for 32 years now. A CLI really shines as a scripting interface, for one program to interface with another. As a user interface it's conceptually flawed from beginning to end.


  • FoxDev

    @sloosecannon said:

    it's a feature that (IIRC) makes the repository almost impossible to work with anyways.

    for a developer, yes. for an automated build system that doesn't want nor need that history it's pretty damn useful.


  • Banned

    @Mason_Wheeler said:

    A CLI really shines as a scripting interface, for one program to interface with another.

    No, CLI is awful interface for scripting and IPC. The fact it's widely used for both doesn't change anything.

    CLI is terrible user interface and terrible scripting interface, but it's the best option if you want a single interface for both. A terrible idea, but very easy to implement.


  • :belt_onion:

    Well yeah. Generally automated build systems use the regular old CLI though


  • FoxDev

    @sloosecannon said:

    Generally automated build systems use the regular old CLI though

    :rolleyes:

    yes, because libgit2 is insufficient for their needs.



  • Why would I install libgit2 and a bunch of other dependencies if I can just run a single bourne shell script?


  • FoxDev

    @ben_lubar said:

    Why would I install libgit2 and a bunch of other dependencies if I can just run a single bourne shell script?

    :rolleyes:

    because the CLI is not an API and i need an API.

    seriously, you are as bad as blakey sometimes.



  • Why do you need an API? What are you doing that's more complicated than a handful of git foo commands can do?


  • FoxDev

    @ben_lubar said:

    Why do you need an API? What are you doing that's more complicated than a handful of git foo commands can do?

    because a program is not a human and the CLI is LITERALLY THE WORST POSSIBLE API


  • :belt_onion:

    Well, that and they usually interface with the CLI already - running mvn, ant, cmake, etc.

    I don't think interfacing with a CLI in a build system is anywhere near as bad as having a GUI interface with it cause (normally) there's a very limited set of commands you'll be running.


Log in to reply