How hard is Git integration? Can Spambots do it?


  • FoxDev

    @sloosecannon said:

    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.

    so....

    UI using CLI as API: bad

    Build system using CLI as API: good

    ... What.

    the.

    actual.

    fuck?



  • git clone -b develop --recursive --depth=1 https://github.com/DFHack/dfhack.git /dfhack
    

    What do you need to do with git that's more complicated than that? And why does your build process require access to APIs?

    You haven't provided any reason for the CLI being worse than an opaque binary API, other than "blakey said so".


  • :belt_onion:

    Yes, because like I said, you'll be running a total of just a few commands.

    git clone to clone the repo initially.

    git branch, maybe, to switch to your selected branch.

    and, if you're doing some sort of automated tagging, git tag, and git push.

    Of course, then you're giving your build system push access to your repo which gives me a bad feeling. So I'd personally steer clear of that too.

    In a UI, you'll be using any number of different commands with many more possible failure modes. It's much better in a UI to eliminate the CLI-related failure modes...


  • FoxDev

    @sloosecannon said:

    Yes, because like I said, you'll be running a total of just a few commands.

    ...

    I'm okay with using the GIT CLI, love the thing, but seriously.

    I cannot believe i'm agreeing with blakey on this one.

    • THE CLI IS NOT AN API
    • THE CLI SHOULD NEVER BE ABUSED AS AN API
    • libgit2 IS MISSING FUNCTIONALITY THAT IS IN THE CLI
    • THEREFORE IT IS NOT A COMPLETE API IMPLEMENTATION
    • BECAUSE IT IS MISSING FUNCTIONALITY PROGRAMS ARE FORCED TO USE THE CLI TO ENABLE THE FUNCTIONALITY THEY NEED
    • THIS IS BAD AND WRONG


  • @Mason_Wheeler said:

    That's a very poor definition, and has been for 32 years now.

    It's intended for users. It's a user interface.

    You might argue it's also a machine interface, but that doesn't change the facts.

    @Mason_Wheeler said:

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

    It's actually really shitty at that, too. Compared to something like AppleScript, which is a real scripting interface. PowerShell is a step in the right direction-- at least it has a reasonable type system.

    @Mason_Wheeler said:

    As a user interface it's conceptually flawed from beginning to end.

    I agree it's flawed and shitty, I've said so enough goddamned times, but that doesn't change the fact that it's designed to be used by human beings.

    In any case, you're still missing the point: nobody's expecting the Git developers to go back to scratch and start over "reborn" with the passion of creating a great user experience-- even if they did do that, they'd fuck themselves because it'd break compatibility with everything.

    I'm just saying the BARE MINIMUM they could do to stop being incompetent dickwads is to provide a stable, complete API.



  • @accalia said:

    UI using CLI as API: bad

    Build system using CLI as API: good

    You're reading "not as bad" as "good".

    Don't be stupid. We're not stupid enough to fall for you pretending to be stupid.



  • @accalia said:

    libgit2 IS MISSING FUNCTIONALITY THAT IS IN THE CLI
    THEREFORE IT IS NOT A COMPLETE API IMPLEMENTATION
    BECAUSE IT IS MISSING FUNCTIONALITY PROGRAMS ARE FORCED TO USE THE CLI TO ENABLE THE FUNCTIONALITY THEY NEED

    I bring up again that even if libgit2 were complete, it still wouldn't enable Git features like pre-commit hooks. Because they're implemented in a shitty way that assumes a virtual console exists.

    Honestly, the Git developers are so incompetent they've kind of just completely fucked themselves entirely. At this point, it's probably impossible for them to release a complete API. Not without deprecating features.



  • @blakeyrat said:

    I agree it's flawed and shitty, I've said so enough goddamned times, but that doesn't change the fact that it's designed to be used by human beings.

    Then it's designed by people who don't know how to design. (Not talking about Git specifically here; talking about CLIs in general.) CLIs are good for programs to communicate for one another, or for an administrator to write up a script file to automate tasks. They're much better than a GUI for those use cases. But for actual non-automated, right-now usability, they are horrible and should never be used, and anyone who designs a system that requires the users (not the administrators, and not developers of other products who want to interoperate with it) to know that a CLI exists is Doing It Wrong.


  • FoxDev

    @blakeyrat said:

    Don't be stupid. We're not stupid enough to fall for you pretending to be stupid.

    well if you are going to be that way, i shan't argue for your position any more, no matter how right i may or may not feel you are.



  • @Mason_Wheeler said:

    Then it's designed by people who don't know how to design.

    I agree entirely.

    @Mason_Wheeler said:

    CLIs are good for programs to communicate for one another, or for an administrator to write up a script file to automate tasks.

    I disagree. AppleScript was a significantly better concept for this kind of work, and allowed the user to script any sort of application that dealt with any sort of data. The only reason current text-based CLIs work for this is because administrative tools (especially in Windows, where most of them started out as GUIs) have been twisted and squeezed into text-based operation. (Tail wags dog.)

    @accalia said:

    well if you are going to be that way, i shan't argue for your position any more, no matter how right i may or may not feel you are.

    You "shan't" be surprised by me getting annoyed at people playing dumb by this point. You've been on the forum longer than a couple hours.



  • @blakeyrat said:

    I disagree. AppleScript was a significantly better concept for this kind of work, and allowed the user to script any sort of application that dealt with any sort of data.

    I couldn't say; I never used AppleScript..


  • FoxDev

    @blakeyrat said:

    You "shan't" be surprised by me getting annoyed at people playing dumb by this point.

    nor shall i be surprised at you misinterpreting comments, either deliberately or inadvertently, and being upset at the false interpretation.

    but what else is new?


  • Trolleybus Mechanic

    I've been pondering writing a tool to better visualise git branches at work into swimlanes or something to separate out feature branches from the rest rather than just lumping the lot together. Since we're a .NET house then the choices are either libgit2sharp, the wrapper around libgit2, which gives me an API to use that finally has reasonable functional coverage but is still incomplete and doesn't appear to have documentation, or executing git subprocesses and parsing text which is disgusting.

    libgit2 says it's a "libgit2 is a portable, pure C implementation of the Git core methods" but what I read is it's really a reimplementation of the Git core methods and not actually related in any way to the git CLI code everyone is using.

    Then I see in the Git 2.7.0 release notes this harbinger:

    So once that's changed, and the official git client changes to use it, then I'm expecting some huge timespan whilst libgit2 reverse engineers it all to support it - and it's only recently that it's even been worth using as an API despite it still having large functional gaps in it.

    I despair.



  • @blakeyrat said:

    I bring up again that even if libgit2 were complete, it still wouldn't enable Git features like pre-commit hooks. Because they're implemented in a shitty way that assumes a virtual console exists.

    So? Can't the virtual console be abstracted by (for example) streams or pipes or something similar in the API endpoints?

    That's an honest question, I'm trying to wrap my head around why a pre-commit hook requires a virtual console and if it's impossible to create an API that would work as expected and doesn't use ugly hacks to work around stuff like that.
    I might very well be missing something obvious though.



  • @OffByOne said:

    So?

    So it's shitty for a core feature of the product to rely a UI infrastructure that may not exist. By making it rely on a console existing, you've just excluded it from running (for example) as a Windows Service.

    (Well, you haven't, because Windows can set one up because they added it as a compatibility thing because it's such a common thing buggy shitty software does. But a correct Windows Service has no access to any type of UI, unless you count the Event Viewer.)

    Are you people programmers? Isn't it obvious that:

    1. The core functionality of an application should exist in a library
    2. A library shouldn't assume it's running in some particular sort of UI?

    @OffByOne said:

    Can't the virtual console be abstracted by (for example) streams or pipes or something similar in the API endpoints?

    Not unless its just an in/out stream to a console. Git expects that a pre-commit hook be able to run, say, Grunt.

    @OffByOne said:

    That's an honest question, I'm trying to wrap my head around why a pre-commit hook requires a virtual console

    The feature itself might be implementable without one. (Might.) The way it's currently implemented in Git, it certainly requires one. Any Git client that wants to run preexisting pre-commit hooks definitely needs a virtual console.

    @OffByOne said:

    I might very well be missing something obvious though.

    It's just yet another example of how incompetent Git developers have blended-together the function of their program with a particular UI.



  • @blakeyrat said:

    So it's shitty for a core feature of the product to rely a UI infrastructure that may not exist. By making it rely on a console existing, you've just excluded it from running (for example) as a Windows Service.

    That's what I want to know: does it rely on a console existing or does it just want a stream to read from and/or write to?

    @blakeyrat said:

    Are you people programmers? Isn't it obvious that:

    1. The core functionality of an application should exist in a library
    2. A library shouldn't assume it's running in some particular sort of UI?

    I never disagreed with either of these points. FWIW, I fully agree with them.

    @blakeyrat said:

    @OffByOne said:
    Can't the virtual console be abstracted by (for example) streams or pipes or something similar in the API endpoints?

    Not unless its just an in/out stream to a console. Git expects that a pre-commit hook be able to run, say, Grunt.

    Why is an in/out stream to a console a requirement to execute system() or equivalent?

    Btw, does git itself refuse to run a pre-commit hook when either stdin or stdout is redirected from/to /dev/null, just because?

    All I can find is that git looks at the return code of the pre-commit hook to determine if the commit should go through or if it should abort. I can't find that it cares about what the hook writes to its stdout, nor that it puts something on the hook's stdin.
    For some other hooks, git does put information on the hook's stdin. That doesn't have anything to do with a virtual console though.

    @blakeyrat said:

    Any Git client that wants to run preexisting pre-commit hooks definitely needs a virtual console.

    Can you provide evidence of that? I couldn't find any.

    @blakeyrat said:

    incompetent Git developers have blended-together the function of their program with a particular UI.

    If what you say is really true, that's bad. Doesn't mean it can't be refactored into a real library with a stable API and a CLI layer (or GUI, or IDE, or …) on top that calls that library to do the actual work.



  • @OffByOne said:

    That's what I want to know: does it rely on a console existing or does it just want a stream to read from and/or write to?

    As far as I know, it simply executes a particular command line, and allows or disallows the commit based on the result code. I don't think it's any more sophisticated than that.

    Ours is configured to run Grunt something. But I usually do commits using VS which ignores pre-commit hooks anyway. (And SourceTree has a checkbox that says "ignore pre-commit hooks".) So I dunno. Maybe it's not an important feature to support.

    But like I said, it's a good example of Git developer incompetence.

    @OffByOne said:

    I never disagreed with either of these points. FWIW, I fully agree with them.

    Then why are you asking?

    @OffByOne said:

    All I can find is that git looks at the return code of the pre-commit hook to determine if the commit should go through or if it should abort.

    Right; but the pre-commit hook is a commandline that needs a console to run on. That's the issue.

    I suppose if the stars line up, maybe you could use ShellExecute in Windows, but I doubt that would work in most cases. Who knows, maybe I'm wrong. (That means your pre-commit hook would need to know the exact path to the .exe, because it couldn't use the console's PATH variable to find it.)

    @OffByOne said:

    If what you say is really true, that's bad. Doesn't mean it can't be refactored into a real library with a stable API and a CLI layer (or GUI, or IDE, or …) on top that calls that library to do the actual work.

    It can't. Because Git developers are incompetent and don't recognize the need to do so.

    Early in this or the other Git thread, I used the term "dancing bear-ware" and linked to the book it came from, "The Inmates Are Running The Asylum", and the more I think about it, the more appropriate that title is for Git. The problem with EVERYTHING we're discussing is that the incompetent developers who have no idea how to develop quality software are the ones running Git.

    When the crazy people are the ones running the show, the sane people have no chance.


  • Notification Spam Recipient

    @Yamikuronue said:

    Eric S:
    the hard work of development is in building the underlying foundation, and [...] the easy part is writing a “GUI wrapper”,
    I will find this man and I will stab him. 🔪



  • @blakeyrat said:

    Ours is configured to run Grunt something. But I usually do commits using VS which ignores pre-commit hooks anyway. (And SourceTree has a checkbox that says "ignore pre-commit hooks".) So I dunno. Maybe it's not an important feature to support.

    CLI git gives you the option to skip pre-commit hooks with git commit --no-verify. Apparently you shouldn't rely on commit hooks being executed with 100% certainty.

    That makes sort-of sense IMHO. A pre-commit hook is client-side, the developer doing the commit should be able to skip it for whatever reason.

    If you want to enforce some policy on commits, server side hooks (pre-receive or update) seem to be the way to go.

    @blakeyrat said:

    @OffByOne said:
    I never disagreed with either of these points. FWIW, I fully agree with them.

    Then why are you asking?

    Your two points weren't an answer to anything I was asking.

    @blakeyrat said:

    the pre-commit hook is a commandline that needs a console to run on. That's the issue.

    That's where you're wrong. The pre-commit hook needs to be executed, but that requires no command line nor a console.
    You could run the pre-commit hook by double-clicking it from within Windows Explorer if you'd like.

    @blakeyrat said:

    I suppose if the stars line up, maybe you could use ShellExecute in Windows, but I doubt that would work in most cases. Who knows, maybe I'm wrong. (That means your pre-commit hook would need to know the exact path to the .exe, because it couldn't use the console's PATH variable to find it.)

    I thought %PATH% was a global environment variable in Windows, not something that's specific to any console or terminal emulator you're running?
    I might be wrong, I don't have a Windows machine at hand to test it out.

    Googling for ShellExecute hints that would be the way to go (actually ShellExecuteEx, since it's impossible to use the former in a synchronous way).

    Except for unaligned stars, what would cause ShellExecuteEx to fail? If "it couldn't use the console's PATH variable to find it", see above: isn't %PATH% a global environment variable instead of a console specific thing?
    In that case, it's the responsibility of the pre-commit hook (or the runtime environment executing that hook) to search the PATH for any external executables invoked by the hook.



  • I've been assuming that libgit2 is just an .so/.dll/.dylib wrapper for the Git internal API. I could be wrong, though.


  • Trolleybus Mechanic

    The closest thing I can find to an answer to that is:

    ... which says it's a reimplementation, not a wrapper.



  • @OffByOne said:

    I thought %PATH% was a global environment variable in Windows, not something that's specific to any console or terminal emulator you're running?

    Some cursory research shows that it indeed does look in the PATH environment variable, I did not know that. CreateProcess does not, however.

    And yes when I say "ShellExecute" you can read that as "ShellExecuteEx". Don't use the deprecated one, duh.



  • @blakeyrat said:

    @OffByOne said:
    I thought %PATH% was a global environment variable in Windows, not something that's specific to any console or terminal emulator you're running?

    [Some cursory research][1] shows that it indeed does look in the PATH environment variable, I did not know that. CreateProcess does not, however.

    Cool. Let's not use CreateProcess then.

    What impact does this discovery have on your assertion that git pre-commit hooks need a console?
    What the hooks need is a way to have %PATH% parsed in order to run external executables and ShellExecuteEx does that. Is there anything else missing that you can think of?

    @blakeyrat said:

    And yes when I say "ShellExecute" you can read that as "ShellExecuteEx". Don't use the deprecated one, duh.
    [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121.aspx

    Cut me some slack. I wasn't trying to be a pedantic dickweed, I wast just trying to be accurate. When I deal with Windows, it's 99% of the time as a user, not a developer. Of that time spent as a developer, 99% I'm not using the C interface.

    I just want to verify if I get the details correct in my mental model. Most of what I know regarding Windows development is through Google and that's sometimes worth as much as you pay for it (especially when the search results are from Stack Overflow).
    You are much more experienced with Windows as a developer than I am, so I try to validate what I found trough your expertise; I'm not trying to nit-pick.

    EDIT: Or, to be pedantic: my shoulder aliens don't add Ex after every Windows C API function name I read.



  • @OffByOne said:

    EDIT: Or, to be pedantic: my shoulder aliens don't add Ex after every Windows C API function name I read.

    You should call ExEx instead. Ex is deprecated.



  • Don't use ExExEx, though, especially if you're near a small child.



  • @OffByOne said:

    CLI git gives you the option to skip pre-commit hooks with git commit --no-verify. Apparently you shouldn't rely on commit hooks being executed with 100% certainty.

    That makes sort-of sense IMHO. A pre-commit hook is client-side, the developer doing the commit should be able to skip it for whatever reason.

    If you want to enforce some policy on commits, server side hooks (pre-receive or update) seem to be the way to go.

    I've been trying to say there's no point of pre-commit hooks in DVCS, thus making all client side hooks completely redundant and no reason to implement them.



  • You don't like the idea of writing, instead of an application, first a library, then an "application" that does little more than expose its functions?

    ...I guess the problem is that while this approach may make sense for a command-line application, a GUI application is supposed to be much more than a mere "testing mockup" like ASP.Net's webservice testing pages. A GUI application is about what you want to do, not how you do it.


  • Java Dev

    Client side hooks may be useful for the dev's convenience. There is more you can put in there than just things to verify integrity of the repository.



  • @hifi said:

    I've been trying to say there's no point of pre-commit hooks in DVCS, thus making all client side hooks completely redundant and no reason to implement them.

    Ahh - HERE'S the argument that says we shouldn't use DVCS in a corporate environment. AT LAST!!!

    I wish we had a pre-commit hook - currently, ours is in the build process. (Well fuck, the build just failed because I didn't insert the correct copyright string.)



  • @Medinoc said:

    ...I guess the problem is that while this approach may make sense for a command-line application, a GUI application is suppo

    Doesn't matter; the CORE WORK of the program should still be done in a library that is UI-agnostic.



  • @dcon said:

    I wish we had a pre-commit hook - currently, ours is in the build process. (Well fuck, the build just failed because I didn't insert the correct copyright string.)

    If your checks are in the build process, then the push and effectively your commits have already been accepted. Do it in a pre-receive hook on the repository and you're good as you can reject the push if it doesn't pass sanity checks.

    Not having a commit preventing hook locally allows you do do whatever you want until you are ready. The whole point of DVCS is to allow you to do your thing locally and all validation is done when you want to publish your changes to others - the central repository in a corporate environment in this case.



  • I can't speak for his build server, but ours builds pull requests before they're ever merged in (and you can't merge a PR if the build was unsuccessful), so having those checks in the build process would be fine.


  • BINNED

    @blakeyrat said:

    ours builds pull requests before they're ever merged in (and you can't merge a PR if the build was unsuccessful)

    This is called continuous integration, and as a policy is a good idea. Maybe should use Travis CI like GitHub projects, then any pull request will be built, and master access can merge only if it at least builds successfully (Green status). No need to ugly pre-commit hooks, you can commit to your tree anything you like; the D in DVCS is supposed to mean something.


  • I survived the hour long Uno hand

    @dse said:

    This is called continuous integration

    What? Seriously, does nobody understand the phrase "continuous integration"? This has nothing to do with continuous integration. It's a good idea, but... damn.

    Continuous Integration: integrating your changes with the changes of other developers as early and often as possible to avoid painful merges at the end of the project, often doing automated validation checks with a CI server as soon as you integrate. It goes hand in hand with Continuous Testing, Continuous Deployment, and Continuous Delivery. You can utterly reject this principle and still build PRs before merging; build a whole project on an isolated, single-dev feature branch, and not integrate until you're done.

    @dse said:

    master access can merge only if it at least builds successfully

    Which is great until Travis has an issue and starts failing builds for no reason.


  • BINNED

    I am still not clear. Why using Travis CI and letting PRs be compiled and checked before they get merged, not CI?

    @Yamikuronue said:

    Continuous Integration: integrating your changes with the changes of other developers as early and often as possible to avoid painful merges at the end of the project

    I do PR on master branch, Travis compiles fine and lets you know it can be merged. If Travis complains I have to rebase on master and do PR again. This is supposed to make "integrating" part easier, no?


    I am frankly trying to learn this.


  • I survived the hour long Uno hand

    Consider: two developers, two changes, one codebase.

    Traditional development says:

    Master: current codebase
    Deva-master: feature 1
    Devb-master: feature 2

    When feature 1 and feature 2 are complete, each makes a PR into master. But if they touched the same files, whoever merges second might have merge hell or break the previous feature.

    CI suggests that dev a and dev b use the same branch, pulling each others changes on a regular basis through development, to ensure that they reconcile differences early. Often, in gitland, this is done by having the upstream repo pull in both changes after each commit, forcing them to integrate and validating that the integration succeeded via unit tests or static checks (or both). With a CVCS, you just use the same branch and get the integration for free, so it's just the checks that have to be added in.


  • BINNED

    @Yamikuronue said:

    With a CVCS, you just use the same branch and get the integration for free, so it's just the checks that have to be added in.

    This same branch can be master branch? so how is it not only a matter of CI trying to merge and running test suits?

    I do not think anything can be for free, some poor soul has to do actually merge if there is any conflict, reading and understanding both features. I guess I will have to use it once to know the actual difference.


  • I survived the hour long Uno hand

    @dse said:

    I do not think anything can be for free

    In a CVCS, there's only one copy of Master: the one on the server. Commits and pushing are the same action.

    In a DVCS, every developer has her own copy of Master, which can be committed to independently and have to be pushed upstream or pulled across to integrate. That's what I mean by "for free": you can't forget to push upstream or pull down.


  • BINNED

    @Yamikuronue said:

    Travis has an issue and starts farting

    Yeah the would be an issue. You don't want this Travis chap farting up the whole building.



  • @blakeyrat said:

    Do you go to the local mall with a jackhammer and tear up the handicapped ramps too?

    No. Lorne has that covered. I just stand behind him snickering uncomfortably and filming him on my phone.


Log in to reply