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

Ship Small Diffs

blog.skyliner.io

Post reply on HN
Print view View original

21–30 of 76 posts

Re: Ship Small Diffs

#21

Post by olau »

notacoward wrote: post #5

Um, no. Keeping diff sizes smaller is nice, but asking for "a few dozen lines" most of the time is too doctrinaire. In many codebases, especially those that are older and larger, even a fairly straightforward enhancement can require a few dozen lines of new code plus even more modifying callers or hooking things together in other ways. Oops, already over the limit. Breaking up patches can even make them less coherent…

I think the point was to keep your changes minimal, not to break the patches up arbitrarily. So if a new feature consists of X and Y, you try to release first X, then Y, not both at the same time, even if they are related.

Re: Ship Small Diffs

#22

Post by tonyhb »

Vendan wrote: post #17
tonyhb wrote: post #13

Earlier quoted context omitted.

The expressiveness of a language directly impacts the amount of code you need to write for a feature. Go is a concise language but it's not expressive - you'll write 4 lines to call a func and check an error. This means that PRs are inevitably going to be larger than a language like Ruby or other languages with metaprogramming.

I think you have those backwards. Concise is expressing an idea in less words, expressiveness is the breadth of ideas that can be communicated. Go is not concise and does not try to be.

+1 totally, thanks for the heads up!

Re: Ship Small Diffs

#24

Post by carterehsmith »

>> Building a web application is a young and poorly-understood activity.

Sorry, no. People have been shipping, and understanding how to ship web applications for... what, 10, 15, 20 years now?

Re: Ship Small Diffs

#25

Post by grigjd3 »

carterehsmith wrote: post #24

>> Building a web application is a young and poorly-understood activity. Sorry, no. People have been shipping, and understanding how to ship web applications for... what, 10, 15, 20 years now?

Compared to the history of agriculture, 20 years is nothing.

Re: Ship Small Diffs

#26

Post by richardwhiuk »

pavel_lishin wrote: post #2

> You don’t need elaborate Git release rituals. Ceremony such as tagging releases gets to feel like a waste of time once you are releasing many times per day. What happens when you ship bugged code and need to roll back?

Just use the commit id, instead of tagging it explicitly

Re: Ship Small Diffs

#27

Post by flukus »

pavel_lishin wrote: post #2

> You don’t need elaborate Git release rituals. Ceremony such as tagging releases gets to feel like a waste of time once you are releasing many times per day. What happens when you ship bugged code and need to roll back?

It's always felt like a waste of time time me, even with SVN. You always know what the released version is and can branch from there if necessary.

Re: Ship Small Diffs

#28

Post by lolsal »

flukus wrote: post #27
pavel_lishin wrote: post #2

> You don’t need elaborate Git release rituals. Ceremony such as tagging releases gets to feel like a waste of time once you are releasing many times per day. What happens when you ship bugged code and need to roll back?

It's always felt like a waste of time time me, even with SVN. You always know what the released version is and can branch from there if necessary.

In larger organizations it is very easy to not have any idea what version is currently deployed. I worked for a company that cut SaaS releases every two weeks, but for various reasons the deployed version might be 1-4 months behind current repo HEAD in engineering. It got even more cumbersome deploying different versions for US vs EU and GOV environments.

It's definitely not ideal, but I'd bet it happens more often than we'd like to admit as professionals.

Another thought - at that same company there were I think 5 or 6 different maintained enterprise mobile apps. Jumping between repos and dealing with the various app stores/approval processes it was easy to get lost regarding what was in production.

Re: Ship Small Diffs

#29

Post by jaibot »

grigjd3 wrote: post #25
carterehsmith wrote: post #24

>> Building a web application is a young and poorly-understood activity. Sorry, no. People have been shipping, and understanding how to ship web applications for... what, 10, 15, 20 years now?

Compared to the history of agriculture, 20 years is nothing.

What about person-years?

Re: Ship Small Diffs

#30

Post by MaulingMonkey »

notacoward wrote: post #5

Um, no. Keeping diff sizes smaller is nice, but asking for "a few dozen lines" most of the time is too doctrinaire. In many codebases, especially those that are older and larger, even a fairly straightforward enhancement can require a few dozen lines of new code plus even more modifying callers or hooking things together in other ways. Oops, already over the limit. Breaking up patches can even make them less coherent…

> Breaking up patches can even make them less coherent as context for each one is lost

A potential solution: Non-fast-forward merge commits. Best of both worlds: Small diffs and large diffs. (I'll also note that I haven't found this to be a problem in practice.)

> and can slow things down if all the pieces have to be pushed separately through a slow CI pipeline.

And can speed things up if the CI pipeline can pinpoint the exact change that broke the build. Fat commits just obscure the underlying problem - although sometimes that's the best you can hope for.

Post reply on HN