Vincent Driessen

No offense, but seems your problems coming your unwillingness to learn git properly. If you would take the time and learn it (reading Pro Git book, learning from visual tools, which there are a ton, etc) (Again, no offense, just suggestion.)

> Huge number, about 148, of commands with many sub-commands that often do non-obvious, even unrelated things.

You don't need to know all 148 of them. If you only know 16 (1/9 of them): add, branch, checkout, commit, config, fetch, log, pull, push, rebase, reflog, remote, reset, show, stash, status, You can do pretty complex things already. For day-to-day usage, these are more than enough.

> git rebase enables users to rewrite history which subverts what should be the main, if not only, function of a version control system.

Git rebase enables very simple workflows, like the GitHub workflow[1], which IMO is quite simple, small overhead workflow, pretty useful and scalable.
Git rebase is also for local repo only. In every tutorial and even git command recommends against pushing rebased branches to an already pushed remote repository. If you keep this in mind, it makes sense.

> ... to rebase heavily to create a false history presenting themselves as fantasy 10X programmers who don't make mistakes, ...

I think the reason is not that they want to hide their mistakes, but to clean the history. Would you rather see typos in a history? IMO it's just cruft, an amend or rebase pretty much just a clean up you can read it more easily, and you…

I think Git is much easier to understand if you understand the underlying data model. The core object in Git (as far as you need to care) is a commit. Each commit holds a link to the commit(s) it was based on. If two commits have the same parent, you have two branches. If one commit has two parents, it's a merge. Individual commits don't know what branch(es) they are a part of.

Branches are just pointers to commits. When you make a new commit on a branch, the new commit is saved and the branch pointer is moved forward to point to the new commit.

Tags point to branches, but they don't get updated. They're supposed to be permanent (but can be modified if you try). If a tag points at a commit and you make a new commit, the tag still points to the original commit.

The only other odd term would be HEAD, which is like a branch that ALWAYS points at what you have checked out at the moment. You'll see this if you make commits without being on a branch (say you checked out an old commit and just started working).

Since branches are just pointers at commits, you can move them around easily. If you make 6 new branches, they all just point at the same commit to start, which is why it's so amazingly fast to do. If you want to undo a commit (that you haven't pushed), you can move the branch pointer to a previous commit. After that when you make new commits it will be like the mistake never existed. (Note: If you accidentally do this, it can be fixed if you catch it soon enough).

When…

No, I wouldn't hire you as-is. Probably not a first-choice intern either.

Some notes on why not:

+ Your web-sume looks rough. As pointed out by others, there are a number of typos (i.e: "and provide an opporunity") not to mention the design itself could use work. If you are GREAT at web design/UX you should spruce it up. Otherwise, kill it and move to a traditional resume. Knowing HTML5/CSS3 today is pretty meaningless, so showcasing that is sort of pointless.

+ There are tons of issues with your resume itself (i.e: "Excellent verbal and written communication skills." despite multiple typos and unclear flow) which need to be addressed. Cut the fluff, point to recent projects & address why they are cool/why anyone should care. Anything that you did 10+ years ago that isn't directly applicable to what you want to do in the near future has no place on the resume.

+ Your bitbucket projects are lackluster. You don't follow good git branching habits, your commits are non-atomic, your code is cumbersome and unfinished in many places. You also seem to use .py files as notes in non-standard ways, introducing weird artifacts and conventions to your projects.

Some notes on how to improve:

+ Learn how to use git productively in a team environment (this means no more working directly out of master). This is a good resource to that end: http://nvie.com/posts/a-successful-git-branching-model/

+ Learn better coding habits in whatever language(s) you are most comfortable with. Your…

I am a huge fan of Gerrit, other than its UI. I ran it along with Jenkins[0] at a previous company. Its review model is far, far, far superior to Github's. As you said, it keeps successive patch sets, and allows for diffs against previous patch sets, rather than only against the original parent. This allows for you to see only the most lastest changes, so you don't have to wonder if anything else was changed and review the entire patch.

> $ git review

I actually wrote a bash script with the same name and a few other shortcuts before my company started working on OpenStack. I was quite pleased with the workflow I provided the team I was on.

$ git start <new-branch> <branch-from>
$ <do work as normal>
$ git review
$ git finish # removes the branch

These three commands along with the git-flow branching model[1] (but not the tool itself), leads to clean, sensible history in my opinion.

I respect that Github tries to maintain a low-barrier of entry to increase use and ease, but I believe there's a way to maintain it while still having a great patch-review model.

0: http://jenkins-ci.org/
1: http://nvie.com/posts/a-successful-git-branching-model/

Thanks for taking the time to provide some feedback. The article that you presented was really interesting and despite being over 15 years old, it seems that its insights are still valid today.

Regarding Gitpilot, I think that our biggest problem at the moment is that maybe we are miscommunicating its value proposition. As it's a compliment to Github and not a replacement. I think you'd also find that it's at least attempting to be goal oriented as opposed to being task oriented like most Git GUIs. For the sake of brevity, Gitpilot is best described as a git-flow GUI [http://nvie.com/posts/a-successful-git-branching-model/, https://github.com/nvie/gitflow/]. (Our branching model is a bit different though)

It is Mac specific at the moment and it's currently awaiting review for the Mac App store. If you're interested, when it's live, I'll send you and your team promo codes so that you can try it out at no cost. If so, send me an email to jp [AT] gitpilot.com

Thanks again.

It is obviously a hard thing to quantify, but relative pain of branching and merging is apparent through the different version control styles commonly advocated/actually seen for both systems. As a simple example, while this (http://nvie.com/posts/a-successful-git-branching-model/) is certainly possible in SVN, I have never actually seen an SVN shop consistently doing that. To the extent that any I have seen do follow that model, they do so essentially at gunpoint, not because it is a pleasant thing to do. On the other hand that sort of thing is exceedingly simple and pleasant in git. As a consequence, in the real world, people are much more willing to employ both with git without any hesitation at all.

Also poorly quantifiable is the sense of fear or anticipation that courses through your veins when you hear the phrase, in an SVN shop, "Hey, I've got a feature branch I want to merge in."