2014-09-12

I don't git it.

A lot of people praise git. I liked it at first, now I don't geet it.

Some weird stuff I've found in git, in no particular order:

  • You can pretend to be anyone. Just change your [user] name and email in .git/config and commit away. As long as when you push you use valid credentials, the commits will be recorded as from someone else. (At least this is possible on GitHub, I know git doesn't implement any specific user access control.)
    * I guess you could try to enforce signing commits but as anything besides the basics, that gets pretty complicated on git.
  • Steep learning curve that keeps getting steeper. Ok: git init, git add, git rm -r, git commit -am, git remote add, git fetch, git merge -ff, git push and pull -u of course, git checkout -b, git reset --mixed, git revert HEAD ... Those are just some of the basics... Ever tried to incorporate git subtree pull -P prefix --squash > into your workflow? I have, it's not fun (keep reading).
  • Its super complicated to collaborate with git-subtrees. Let's say you have a central repo that other people can only read from, and you git subtree pull into some of its folders from the actual repos others can write to. That should make sense, right? In fact, initially, when guy1 and guy 2 clone your central repo, they need only add the remote for the subtree they'll both work on, and each can start using it by committing changes in that folder and using subtree push -P (subtree pull-ing first if necessary).
    * This already creates some confusion though, because those commits exist both in their local repo and in the subtree remote, but their local ones will never end up in central repo/origin; they can only pull from that one, remember? So their local branches will always be "ahead" which is technically fine.
    However:
    1) If they don't use --squash, that will only work once, because when you subtree pull their changes in the central repo and push to it, they'll want to pull the central repo locally to have eachother's changes naturally, and they can do so, but only the one who did the latest subtree push can continue pushing. The one(s) that git pull and git subtree pull but didn't git subtree push last will keep receiving an error when trying to subtree push, telling them to pull first. In fact they may need to delete the branch entirely and create it again (possibly loosing work along the way).
    2) If you DO use --squash, the above issue seems to be avoided BUT squashed subtree pulls may feel free to bringing back files you deleted before for some freakish reason (especially when some times they --squash and some times not). I haven't been able to wrap my intellect around this completely as of yet. Prolly just cuz nun o diz don't make any sense at all.
    * You could, I assume, create a separate branch for each subtree, to avoid some or all of these problems, I should try that and report back (in case anyone cares).
  • Another oddity with subtrees is that when you add one, if you don't do so from a remote having fetched the remote first, it may not work (or if you are in windows and use a backslash in --prefix). And once you add a subtree from a named remote and branch, the subtree seems to track such remote for subtree pulls (i.e. you only need say git subtree pull and it knows where to pull from) but not for subtree push. Furthermore, god knows where .git keeps this "tracking" info.
  • Inconsistent syntax. Come on... git remote remove vs. git branch -D is only the tip of the iceberg. Referring to tree-ishes, commits and branches is also inconsistent among commands where using slash is sometimes necessary, sometimes causes errors (e.g. git branch -u origin master). You need to be very careful and keep consulting the incomplete documentation online because it's too hard to memorize any of these arbitrary differences. Other inconsistencies:
     git remote -v vs. git branch -a vs. git stash list (to list stuff)
     git pull/push have way more options than git subtree pull/push
     ...

See another good criticism of git at is this guys' post.

#nomegusta. BUT WHADDAY'ALL THINK ?

No comments:

Post a Comment

Simple server load test with cron and ab (Linux)

Load testing "refers to the practice of modeling the expected usage of a software program by simulating multiple users accessing the p...