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

261–270 of 435 posts

Re: Idiot Proof Git

#261

Post by thfuran »

theptip wrote: post #191
danwee wrote: post #130

Git commit crafting (and rebase to achieve it) is overrated. If you care about crafting beautiful series of commits so that the future readers understands what's going on: don't. Context is more useful to find out why something changed. Example: - you build feature F that is touching N files and M lines of code - you craft your git commits so that each of them is atomic and "understandable" on its own - now if I want…

I think you are arguing against an extreme version of the practice. Normal advice is to shoot for 100-200 lines in a commit, not split that into ten commits that each change 15 lines. If someone is splitting 100-line commits into 10-line commits, I would advise not doing that. However the direction that people normally err (IME) is submitting 500-2000-line commits which conflate multiple atomic changes. I would also…

I don't think lines of code is much better an estimate of commit complexity than it is of productivity. I could make a 1,000 line change by changing the signature of something that gets called a lot, but that's essentially atomic. I could make a 200 line change by sightly updating 100 totally unrelated functions and that's probably totally nuts.

Re: Idiot Proof Git

#262

Post by Arelius »

anonuser123456 wrote: post #159
mattarm wrote: post #120

Earlier quoted context omitted.

A rebase creates new commits from old commits semi-automatically. Git then has no permanent record of the old commits, and even if you want to get back to them right away it requires some delicate git surgery. This is why you can't generally share work using a rebase workflow. It is not a big deal in practice in most every case, but in a version control system it is a little bit odd that rolling back such a fundament…

> even if you want to get back to them right away it requires some delicate git surgery. The reflog tracks rebase commit history. No surgery required. >This is why you can't generally share work using a rebase workflow. Rebase of public facing commits is not discouraged due to data loss. It is discouraged due to the possibility of someone creating change sets off the published work, and then the update re-writing the…

They might be exaggerating a bit the amount of work to recover it immediately, but resetting a tag to a commit in the reflog might be considered at least a minor git surgery. And that’s assuming no public pushes have been made. Then all bets are off and it’s surgery’s time.

Re: Idiot Proof Git

#263

Post by OkayPhysicist »

prettyStandard wrote: post #236
OkayPhysicist wrote: post #194

Earlier quoted context omitted.

At some point, every junior is going to mangle something, and need a senior to sit them down and give them the git reflog talk. It's an inevitability, and should be embraced as a natural part of the evolution of a developer.

Haha. what's the git reflog talk? To be clear I know what reflog is, but what's "the talk"?

Just the explanation of "no matter how bad you've fucked up your repo, as long as you haven't run 'git gc' or waited a few years, all you need to fix it is to find the commit hash from git reflog, git checkout that hash, and then git branch to give you an easily accessible reference to the commit". Followed by some pointers on how to efficiently dig through reflog.

It's pretty freeing to realize that it's basically impossible to lose committed code.

Re: Idiot Proof Git

#264

Post by Arelius »

coding123 wrote: post #259

I love git, but I have to be honest about one thing: It's definitely hard on purpose and introduces hard on purpose features (and naming conventions) to weed out people. rebasing and squashing and tracked/untracked. Yes they all have a place, but has anyone noticed with SVN it's just commit, merge and branches. Would it be impossible to make git with svn's UI?

Yes, svn hides and pushes most of the complexity to the users workspace, and just gives up when any sort of complexity happens.

Git could clearly be improved, but much of sun’s ease is due to hiding the complexity of development.

Re: Idiot Proof Git

#265

Post by umvi »

ajkjk wrote: post #216
danpalmer wrote: post #2

Big fan of Git style guides in teams. We had one at Thread. It was common for engineers to come in and find we didn't do rebasing and find it weird, but we took the opinion that history should be exactly what you actually did, not some clean and idealised version of what you wish you had done. There are advantages and disadvantages to this, but having a defined approach was the most important aspect. Also the fact th…

gosh, wow, I want the opposite of that for any project I work on. In the last five years I have never used a merge commit and I love it. I'd honestly prefer a version of git that doesn't have em.

Without merge commits you can never have more than 1 long-lived branch because said long-lived branches will not have any common ancestors which makes pulling changes between them a nightmare (literally every file will be in conflict)...

I like linear histories too, but if you have a production branch and a development branch you need merge commits between them.

Re: Idiot Proof Git

#266

Post by mmmmmbop »

weaksauce wrote: post #253
Arelius wrote: post #241

Earlier quoted context omitted.

Sure can, for instance a hg-like commit stages system for rebase would prevent a lot of rebase caused issues.

> hg-like commit stages system not familiar with what you're referring to... can you elaborate?

It refers to Mercurial, another really popular distributed revision control system.

Re: Idiot Proof Git

#267

Post by Arelius »

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.

No, your not missing out… I mean, it’s a powerful tool, and like any tool, learning to use them can be helpful. Having said that, rebase is a tool that I find myself compelled to use more often than I feel it’s actually useful to use.

Re: Idiot Proof Git

#268

Post by Arelius »

jarek83 wrote: post #81

Why use risky rebase while you can just squash all into one commit and push it via intermediate branch (something that Github does as an option)? I prefer to be worry free than always be ready for someone screwing up a branch.

To be fair, squash is a form of rebase.

Re: Idiot Proof Git

#269

Post by corytheboyd »

Aliases don't make git easier to understand, they make one specific git command require typing fewer characters to run.

I am not against making aliases, but just saying, if you don't have an understanding of the commands they run, you'll still one day be in a state you don't know how to fix, and THAT is when people "lose their code" etc.

You use git every day, it's worth learning and understanding. You don't need to be a pro, but you need to be good enough.

Re: Idiot Proof Git

#270

Post by theptip »

thfuran wrote: post #261
theptip wrote: post #191

Earlier quoted context omitted.

I think you are arguing against an extreme version of the practice. Normal advice is to shoot for 100-200 lines in a commit, not split that into ten commits that each change 15 lines. If someone is splitting 100-line commits into 10-line commits, I would advise not doing that. However the direction that people normally err (IME) is submitting 500-2000-line commits which conflate multiple atomic changes. I would also…

I don't think lines of code is much better an estimate of commit complexity than it is of productivity. I could make a 1,000 line change by changing the signature of something that gets called a lot, but that's essentially atomic. I could make a 200 line change by sightly updating 100 totally unrelated functions and that's probably totally nuts.

Sure, it's just a rule of thumb, not a hard requirement. In my experience most functional/behavioral commits benefit from being in the 100-250 line range, and it's more common for engineers to make things too big rather than too small. YMMV.

As you say, non-functional refactors can be bigger while still being readable/comprehensible (but I think it's important to keep them scoped as such, and commit crafting is important for this).

Post reply on HN