How hard is Git integration? Can Spambots do it?
-
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".
-
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
, andgit 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...
-
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
-
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.
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.
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.
-
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.
-
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 NEEDI 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.
-
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.
-
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.
-
Then it's designed by people who don't know how to design.
I agree entirely.
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.)
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.
-
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..
-
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?
-
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:
- Prepare for Git on-disk repository representation to undergo
backward incompatible changes by introducing a new repository
format version "1", with an extension mechanism.
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.
- Prepare for Git on-disk repository representation to undergo
-
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.
-
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:
- The core functionality of an application should exist in a library
- A library shouldn't assume it's running in some particular sort of UI?
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.
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.
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.
-
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?
Are you people programmers? Isn't it obvious that:
- The core functionality of an application should exist in a library
- 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.
@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.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.
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.
-
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.
I never disagreed with either of these points. FWIW, I fully agree with them.
Then why are you asking?
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.)
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.
-
Eric S:
I will find this man and I will stab him.
the hard work of development is in building the underlying foundation, and [...] the easy part is writing a “GUI wrapper”,
-
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
orupdate
) seem to be the way to go.@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.
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.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 (actuallyShellExecuteEx
, 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.
-
The closest thing I can find to an answer to that is:
-
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.
-
@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 andShellExecuteEx
does that. Is there anything else missing that you can think of?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.aspxCut 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.
-
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.
-
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
orupdate
) 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.
-
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.
-
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.)
-
...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.
-
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.
-
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.
-
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.
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.
-
I am still not clear. Why using Travis CI and letting PRs be compiled and checked before they get merged, not CI?
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.
-
Consider: two developers, two changes, one codebase.
Traditional development says:
Master: current codebase
Deva-master: feature 1
Devb-master: feature 2When 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.
-
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 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.
-
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.
-
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.