10 Things I Hate About Git Far More Than Steve Bennet Does

This blog is inspired by Steve Bennett’s accurate opinion about what’s screwy about GIT.

As a developer who has struggled through the learning curve of every Source Control system available since Visual SourceSafe in 1994, I have to agree with the cake, the pan and the frosting in Steve’s article. And here are some sprinkles:

The PRIMARY ISSUE for developers at the local end of the GIT ‘tube’ (it ain’t a pipeline by far) is the management of the sub-tree of commits that represents the ‘feature’ or ‘fix’ or ‘what I am working on’. This starts with the common commit that is the commit named as the branch created by a developer as the version of the repo to clone or checkout or otherwise download to his local system as the ‘working copy’.

So I will eventually demonstrate in this blog that this is the PRIMARY ISSUE. But first, to put a shiny black eye on the most intractable sources of overall confusion in GIT,  here’s my ‘hit list’.

The totally disrespectful and immensely irritating aspect of GIT is that all the operations, and hence the operation names, are completely .git-folder-centric. This is inane since there is no identity or management logic in the folder. It’s like naming every UI operation by its database operation title.

The real corkscrew in the optic nerve here is that that folder centrism requires a Rubic’s-cube-trained instinct to determine what the command structure is doing, to what, and for whom. This results from the astounding fact that there is no ‘endedness’ to any of the operations.

That is the origin (sorry, Linus absconded with every possible synonym in this domain) of the Operation Titles that look like they represent combinations of more granular operations. These are actually definitions designed to identify the fact that one of the low-level, data-structure manipulation operations  have been wrapped in an ‘endedness’ attribute.

So every operation must have a ‘directional title’ in addition to its descriptive name. This is why we have to have artifacts like ‘pull-request’ to describe a merge from the commit that is pushed to the remote as the ‘branch’ that was modified by the developer on their ‘local’ ‘working copy’. And then we have the ‘pull request’ that (maybe) sets a flag to trigger the  ‘pull’ operation to  merge the local commit into the master branch. Again, Pull request and Pull are also wrapper titles that indicate the ‘endedness’ of these merge operations within the context of the remote repo.

The fact that the .git folder is called the ‘repo’, the ‘working copy’, ‘local branch’, ‘last commit’, and many other things is another (probably not the last) factor multiplying the house-of-mirrors context of managing the squishy tree-structure. Those names are not consistently treated as ‘states’, which might make actual sense. But they are rather ephemeral titles attached to .git folder according to the operations currently being performed. (And again, this has to be multiplied by the specific endedness and repo location attributes of that current context) This is where the problem of the totally irrational command structure penetrates the pavement with all the subtlety of a roadside bomb and turns the whole GIT experience into a flying disaster zone filled with unidentified whizzing objects!

For a view into one of those disaster zones, consider any of the thousands StackExchange posts that pointlessly try to answer GIT questions. Astoundingly, no StackExchange moderator is ever moved to limit the endless variety of comments that various self-defined GIT aficionados spew forth, not one of them using the same terminology, technique, or perspective. This demoralizing result is perhaps the most depressive experiential proof of the utter failure of the GIT system to provide a useful, or even viable experience for developers.

It’s clear that those developers who defend GIT have never really considered or enjoyed the benefit of a Source Control system that dependably, simply, non-intrusively, performs its secure, back-end services without the human burdens required by GIT. I suspect those developers are still starry-eyed by their achievements in getting to a useful skill level with the ‘fascinating data structure’ inside a GIT repo– foo! I say to your bar!

So.. back to the PRIMARY ISSUE.

Everything that is of critical importance to a developer at the local end of the Source Control Process context (not a GIT endedness context) occurs between the HEAD and the common commit that is the connection between his ‘local’ branch and the root structure that is his local copy of the the tree-structure of commits that mirrors the remote repo.

In a living tree this is represented by the points on a tree trunk that represent the tip of the upper portion of the tree trunk, the ‘appical medistem‘ and any ‘secondary medistems’ that appear on the trunk below the tip. Those secondary medistems are the starting point for branches. Until the apical medistem is nipped or damaged, no secondary medistems appear on the trunk: its a simple straight line for all tree-like operations.

All other Source Control Systems operate like a tree trunk before the apical medistem is messed with. Git is like a tree trunk with a damaged apical medistem and is therefore capable of producing an unlimited supply of secondary medistems. The common commits are the starting points for the branches that developers work on. All operations by developers happen between the secondary medistem and the apical medistem of their local branch.

But, of course, the operations developers have to use are all identical to the base operations used through out all ‘high-level’ GIT processes. So all the operations (and their problems) require a re-definition for this most local of contexts in the GIT workflow. The real and inescapable consequence is that a competent vocabulary of operations and tool implementations should exist for these critical operations in the same way that they have been overloaded on the base GIT operations for management of the data-structure in the remote context.

That re-definition and the tools to perform the specific tasks that developers need within the local context do not exist. All the tools so far provide tool operations that are named and structured to represent the local-to-remote context. To be specific, what is needed are tools that provide top-level views and tooling to perform the operations needed by developers at the local tree level.

Those new tool features should mirror the type of diagrams that appear in training sites and books: small tree and branch fragment diagrams in which the remote repo’s tree structure is represented by the last common commit, the secondary medistem that is the ‘root’ of the local branch and its sequence of commits.

This type of solution will not solve the overall defects of the hideously multi-dimensional GIT workflows, uneven layers of irregularly duplicated command structures, the fundamentally flawed, context-agnostic, directionless, dislocated, impossibly unmanageable, multi-recursive data-structure, and all the unidentifiable, unconquerable consequential problems that this situation we call GIT presents to us.

But perhaps, with a real examination of the problems, we can take the basic infrastructure that has grown up around this failed experiment and begin re-defining and re-tooling the cloud platforms, then the developer level tools and integrations to that they are composed of clear, consistent, context-based and semantically clear operations within a dependable and simple vocabulary developer and administrator interactions, and finally then crack the lopsided coconut of a data structure and replace it with something that represents the objects that exist in real-life Source Control domains!

Advertisements

One Comment on “10 Things I Hate About Git Far More Than Steve Bennet Does”

  1. arnebab says:

    Regarding the clear operations and interactions: Do you know my branching strategy article? It shows how to boil down all interactions to three simple rules:

    (1) you do all the work on default – except for hotfixes.

    (2) on stable you only do hotfixes, merges for release and tagging for release. Only maintainers touch stable.

    (3) you can use arbitrary feature-branches, as long as you don’t call them default or stable. They always start at default (since you do all the work on default).

    http://www.draketo.de/light/english/mercurial/complete-branching-strategy

    It is for Mercurial, though.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s