refactor(git): common code to a generic git cll

[hinell]

git-integration-refactor.mov

• keep runner internal logic
• add generic git.cli thin-client for git command
• add dev comments
• required to proceed with feat(actions): git-aware cut / paste / rename fs actions #2542 PR

[alex-courtis]

This works for the very limited testing I've done.

I appreciate all you efforts to improve the codebase, however this has gone much further than a refactor.

Please restrict this PR to a simple refactor: move existing code and change only what is absolutely needed.

[alex-courtis]

How and why does this exceed limitations?

We should resolve the root cause rather than working around limitations.

[hinell]

Lua-language-server doesn't have @function + @params to force a type of a variable. The above sets the same LSP completion signature for both M.git and M.cli.

You can contribute here: https://github.com/LuaLS/lua-language-server
Tracking issue: LuaLS/lua-language-server#1456

[alex-courtis]

Why do we need to force type to coerce the signatures?

Can you not just use unique names i.e. do not overload .git?

Unnecessary fragile code to work around language server limitations is not acceptable.

[hinell]

M.git = setmetatable({}, {
  __call = function(_, ...)
    return M.cli(...)
  end,
})

The above creates M.git both as namespace and callble M.git() property and annotation make sure that LSS recognized this:

M.git()
M.git.mv()
M.git.is_tracked()

This is actually used in my actions.git PR to extend CLI. with few commands.

Refactored in next revision.

[hinell]

A side note on dependency injection & code portability & reusability

--- ./bar.lua
local Foo = require("foo")
M.Foo = Foo

...
function M.public_fn ()
    M.Foo.xyz()
end
return M

The above is a demo of variable reexport. It's a programming approach to make code extensible and therefore - reusable (or hackable). It allows reassignation of basic functions / structures (injection) by downstream consumer of bar.lua code without touching internals of the bar.lua itself.

In a typical use case consumer of bar.lua may do something like this:

--- ./baz.lua
local b = require("bar")
b.Foo = FooExtended 
b.public_fn(...)

This is useful in cases where you want to extend Foo and dont' want to touch baz.lua, but use the latter with extended Foo. It comes at zero cost and only brings benefits.

[alex-courtis]

A side note on dependency injection & code portability & reusability

--- ./bar.lua
local Foo = require("foo")
M.Foo = Foo

...
function M.public_fn ()
    M.Foo.xyz()
end
return M

The above is a demo of variable reexport. It's a programming approach to make code extensible and therefore - reusable (or hackable). It allows reassignation of basic functions / structures (injection) by downstream consumer of bar.lua code without touching internals of the bar.lua itself.

In a typical use case consumer of bar.lua may do something like this:

--- ./baz.lua
local b = require("bar")
b.Foo = FooExtended 
b.public_fn(...)

This is useful in cases where you want to extend Foo and dont' want to touch baz.lua, but use the latter with extended Foo. It comes at zero cost and only brings benefits.

I do not appreciate being lectured to about design patterns. I am rapidly losing patience.

All codebases have flawed structures, antipatterns, inefficiencies, repetition, safety issues etc. etc. Project developers are very aware of these issues however lack the time and priority to resolve them. No codebase will ever be perfect.

Please prove your skills first via several contributions. We may then speak, respectfully, about improvements.

[alex-courtis]

Please push discrete commits to the PR rather than amending or squashing etc.

A changelog is necessary so that the reviewer can see what has changed since the last review.

[hinell]

Removing extra input arguments checks is really dumb. If we don't check input, we risk internal consumers of the arguments to become error-ridden.

This is not how mature programming is done lol.

I will remove them in next revision for now, but it's really dumb and heavy nitpcking. This will ensure that the code is less error-prune.

[gegoune]

Removing extra input arguments checks is really dumb. If we don't check input, we risk internal consumers of the arguments to become error-ridden.

This is not how mature programming is done lol.

I will remove them in next revision for now, but it's really dumb and heavy nitpcking. This will ensure that the code is less modular.

I strongly suggest you that don't send comments like this any more. Let this one be the last one, ok?

[alex-courtis]

@hinell you are no longer welcome in the nvim-tree community.

Your behaviour is rude, uncooperative, condescending, argumentative and very disrespectful. This behaviour is pathological and I don't foresee your changing.

You have wasted a lot of the nvim-tree community's time with your unwanted, misinformed intrusions and naive, unsolicited advice.

Listen mate: you need to take a good hard look at yourself and Grow Up. Any potential employer seeing your github behaviour will run a mile.

[alex-courtis]

Removing extra input arguments checks is really dumb. If we don't check input, we risk internal consumers of the arguments to become error-ridden.

This is not how mature programming is done lol.

I will remove them in next revision for now, but it's really dumb and heavy nitpcking. This will ensure that the code is less error-prune.

For the record:

Internal functions should handle all inputs gracefully. Throwing exceptions on argument mismatch is unacceptable unless they are explicitly handled by the caller.

Arguments are "checked" when they are nilable or have varying type.

Some pieces of data are assumed and known to be valid and complete, such as options. These are not checked at all as it is impractical and of no real value.