Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Idiot Proof Git

softwaredoug.com

Post reply on HN
Print view View original

221–230 of 435 posts

Re: Idiot Proof Git

#221

Post by nerdponx »

huimang wrote: post #54

The problem with git is hardly anyone reads the fucking manual. Git is not hard. The UI is inconsistent, but documented. When you just foist commands onto people, you can't be surprised when they fall off the happy path and don't have the mental model to understand how to fix it. There's no such thing as "idiot-proofing" for people who don't RTFM. --force-with-lease as a default is a really bad idea. Copying random a…

> The UI is inconsistent, but documented.

The problem is that the inconsistency means that you need to constantly refer back to the manual until you have a huge amount of arcana memorized.

Not only that, but it's not always easy to find what you're looking for in the manual.

Yes, programmers should all at some point read the first few chapters of Pro Git, and at least skim through the "internals" chapter.

But idiot-proofing goes beyond babying people who don't want to read docs. Even people who do read docs and care a lot about learning their tools make mistakes and forget things occasionally.

> --force-with-lease as a default is a really bad idea.

Agreed.

> Copying random aliases is a bad idea.

Agreed, but looking at other people's aliases to get ideas and borrow useful snippets is a great idea.

Re: Idiot Proof Git

#222

Post by jcon321 »

Idiot proof git is handled by protecting ALL branches and requiring a merge/pull request. Not a fan of aliases unless created and used personally.

I'm a tech lead for 2 large scale web projects. Rarely will I traverse git log for anything besides the last few commits. If I ever wanted to see the history of something I would just lookup the merge/pull request, or look at the blame on individual files or lines within that file. Having a non-rebased commit history at that point is much more clearer on why/what changed.

I guess anyone who would care for a pretty git-log does not have adequate tracking outside of the source code for requirements --> implementation. Guess I'm used to more stricter guidelines, because I could never see myself working on a project where something is committed that didn't derive from some type of identified requirement.

Re: Idiot Proof Git

#223

Post by horsawlarway »

user3939382 wrote: post #113

.gitconfig: [alias] add-commit = !git add -A && git commit .bash_profile: function save () { git add-commit -m "$*" && git push } Use like: $ save This is a commit message This adds changed files to a commit with this message and pushes it to remote. Also: alias mkpr='git push && gh pr create -d -f -B develop | grep https | xargs printf -- '%s/files' | xargs open' Open a PR from current branch based on develop and op…

Commit accepts the -A flag. You can simplify it to just

  function save ()
  {
    git commit -am "$*" && git push
  }

Re: Idiot Proof Git

#224

Post by sixstringtheory »

dmuth wrote: post #163

I wrote an open source project that may be useful to people here: https://github.com/dmuth/git-rebase-i-playground It lets you create a Git repo with synthetic commits and has sample exercises for doing different things within that repo, such as removing commits or squashing commits. (along with hints and answers) Building this project helped me understand the ins and outs of Git much better and I suspect there will…

This seems like something that should be used in hiring filters, maybe right after fizzbuzz.

Re: Idiot Proof Git

#225

Post by __blockcipher__ »

G3rn0ti wrote: post #123
aulin wrote: post #115

Earlier quoted context omitted.

Why would you have to force anything with rebase? you rebase your feature branch against main to rewind it on top of it and clean up history so you can do a clean fast forward merge. Squashing is bad for anything non trivial, you want small independent commits: easy to review, easy to revert, easy to blame if something goes wrong.

As soon as you pushed your branch to remote (which I tend to do for backup reasons especially after working hard on a solution) rebase only means trouble.

Not if it's the remote for your own dev branch. It only matters if the remote branch is being (actively) used by other people.

Unfortunately I've met far too many who have your "remote" superstition. I remember arguing this exact point in my last gig, when someone was mad at me for force pushing my own remote branch that nobody else was using nor should have been.

Re: Idiot Proof Git

#226

Post by lelandfe »

huimang wrote: post #54

The problem with git is hardly anyone reads the fucking manual. Git is not hard. The UI is inconsistent, but documented. When you just foist commands onto people, you can't be surprised when they fall off the happy path and don't have the mental model to understand how to fix it. There's no such thing as "idiot-proofing" for people who don't RTFM. --force-with-lease as a default is a really bad idea. Copying random a…

As a counterargument, git is quite hard, and I see smart engineers make seemingly simple errors frequently. Its documentation is sprawling and verbose, and its UI "porcelain" is frequently terrible.

Did you know you can use `git fetch origin master:master` to update an un-checked out local branch? Go find where that's documented: https://git-scm.com/docs/git-fetch

Spoiler, here's all you get:

> The format of a parameter is an optional plus +, followed by the source , followed by a colon :, followed by the destination ref . The colon can be omitted when is empty. is typically a ref, but it can also be a fully spelled hex object name.

Just a truckload of jargon. There's thankfully one code sample to give context, but it's at the bottom of the page – nearly 7,000 pixels of scrolling away from the description of it.

Re: Idiot Proof Git

#227

Post by __blockcipher__ »

willio58 wrote: post #150
aulin wrote: post #137

Earlier quoted context omitted.

If you keep merge commits you can get the full diff at once and see all the context you need, if you don't you can still write meaningful commit messages that identify the feature you're working on so that in the future you can still do a diff between the first and the last commit and see it all at once.

Yeah if you just use commits as they are intended then the complexity of git drops off massively. I’ve used got for a decade and want to know how many times I’ve rebased? Zero

I am deeply suspicious of people who claim to have never rebased. I've never met such a person who didn't have absolutely disgusting commits: either (1) no commit body to explain the context of why a chance was made, for patches that clearly needed one, (2) random merge commits in the middle of the actual commits because they don't know any workflow besides merging master into their ongoing dev branch, or (3) massive pull requests (if using a pull request workflow) that touch 30 files and implement way more than just the feature the branch was supposed to be for.

It's also a big sign to me that the person probably rarely if ever actually spelunks through the git log to understand why a certain change was made. Because if one does, they very quickly discover why a workflow involving sane rebasing onto origin/master produces such a better history.

There's times when merge commits are appropriate, but they are few and far between compared to the endless abuses of merge commits by people who don't understand git in the slightest (my definition of "don't understand git" is someone who can't visualize the DAG)

Re: Idiot Proof Git

#228

Post by __blockcipher__ »

prepend wrote: post #170

I just never rebase. Am I missing out? It seems the only major advantage is to reduce the number of items in the history and that doesn’t seem very important to me.

Yes, you're missing out. Rebasing isn't about reducing the number of items in history, although it can do that too. It's about having a sane, readable history.

If you write two commits in your local feature branch, then pull master in and generate an ugly merge commit, and then stack two more commits on top to your local feature branch, and then finally get all that mess merged to master, you have a difficult to read history because of the merge commit randomly in the middle. Whereas if you instead rebase onto origin/master (after fetching of course), you get a nice history where your feature branch commits are cleanly on top of origin/master, so there's no crazy merge commits in the middle.

Most people just use git as a fancy save button, and therefore never actually use the git log / git blame to answer questions about why some part of the codebase is the way it is, and therefore they never realize why their merge commit insanity is so destructive to the usability of the git log.

Re: Idiot Proof Git

#229

Post by jcon321 »

prepend wrote: post #170

I just never rebase. Am I missing out? It seems the only major advantage is to reduce the number of items in the history and that doesn’t seem very important to me.

For a 1 man team there is no point. Even for a 1 man team with a local and remote repo there is no point, because your local branch is always the same as the remote branch.

For a 2+ man team that does not protect the remote repo (i.e., don't require merge/pull requests, and you can commit/push directly into remote branches), then there is no point because... When you go to push a branch and remote complains about changes existing on remote, so you must pull first. You issue a pull and that does a fetch/merge into your local (commits are overlaid in order by date committed - some people complain about this and is why they rebase (commits from remote are back filled, and then your commits are inserted)).

For a 2+ man team that does protect the remote repo, and does require merge/pull requests then an explicit rebase or merge is needed, sometimes. At the end of the day you should be creating a merge/pull request from a source branch that has all of the changes as the remote target (at that point in time) to help the reviewer/approval only see your changes. If you updated your local branch via a rebase then the commits related to your changes are all in order, if you updated your local branch via a merge then the commits related to your changes are interlaid between other commits that happened around the same date). But really that's only a problem if someone cares to use git-log and not the 100 other ways to review history.

Re: Idiot Proof Git

#230

Post by quesera »

jgworks wrote: post #168

This is off topic: I have a dumb git question and I can never seem to formulate a google search that will help me. I use a Mac and for some reason I am able to use `head` (lowercase) instead of `HEAD` (uppercase) in every command and its trained in my muscle memory. So when I go to another computer, this shortcut isn't there, so when I type `git reset --hard head^` I get an error, and I have to go back and change it…

> Anyone know of a configuration option or something somewhere that I can enable this?

I'd suggest that you retrain yourself instead. "HEAD" and "head" are not the same thing, and any fakeout configuration to change that will also be nonstandard and not available everywhere.

The underlying issue is that HEAD is the label Git uses for the reference to the top of the repo. It's saved in the filesystem as .git/HEAD.

MacOS filesystems are case-preserving by default. Linux/POSIX filesystems are case-sensitive by default. I consider this a bad default setting in macOS. Try "cp FILENAME filename" sometime. :(

Anyway, consequently, on default macOS, "head" will be remapped to "HEAD", if "head" does not exist. Watch out for "Head" and "hEaD" though. Of course those won't happen in normal Git usage (though they could be valid, and different, tag names!).

My suggestion is to not let bad macOS defaults creep into your habits. And to not make things even more weird by trying to reproduce their bad behaviour in non-macOS environments.

Post reply on HN