Oh god I feel so called out. I wish I paid more attention to my commit messages but I’m usually too busy fixing the directory structure and refactoring. Sigh.
Master should just have the feature description commits, not the hundred commits it took to get there after refactoring the code for the 3rd time and pulling changes from master since it’s taken so long to get done.
Yeah I worked at a place like that, but it made sense because we were also expected to keep PRs small, so a good commit message for several squashed ones was perfectly fine.
I prefer that approach. We work with smaller tasks, so it makea more sense, plus it helps keep the master clean and if you want a more detailed view of the specific commits, you just have to click on the link to the PR. It’s a better way to organise it IMO
I wish this was exaggerated, but it isn’t at all. Every time I try to learn Haskell, I end up in some tutorial: “You know how you sometimes need to represent eigenvectors in an n-dimensional plane with isotonically theoretical pulsarfunctions? Haskell types make that easy!”
I was scared of reflog too. Had to use it for the first time recently after I accidentally’d a branch that I hadn’t pushed to remote yet. I was so glad that I could recover it all in <5 commands.
Title text: If that doesn’t fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of ‘It’s really pretty simple, just think of branches as…’ and eventually you’ll learn the commands that will fix everything.
To be fair: snaps can work for all kinds of things all over the stack from the kernel to individual applications, while flatpak just does applications. Canonical is building a lot around those abilities to handle lower level things, so I guess it makes sense for them.
IMHO flatpak does the applications better and more reliably and those are what I personally care for, so I personally stay away from snaps.
Some people (like myself and other scientists/mathematicians), write software for specific fields so if you follow them you find it out what work they are putting out, and issues they find in other software etc.
Don’t just summarize the content though, summarize the rationale or how things connect. I can read your diff myself to see what changed, I want to know the logical connections, the reason you did X and not Y, etc.
Or just say “stuff” and provide that context in the PR description separately, no need to overdo the commit log on a feature branch if you’re using squash merges from your PR.
I think it depends what branch your local version of the repo is set to. If you’re already in master then it’ll push there, if you’re in a testing branch then you can push it straight to master instead by telling it to
I was being more evil than that, saying that if one is gonna push direct to main, might as well maximize the possible damage to everyone else’s branch.
Yup yup, usually you’re on a branch, sometimes a tag. I mean it’s all just pointers to references at the end of the day. I tend to treat Git like a story book, some folks still act like it’s SVN.
Yeah, the thing is, "a monad is a monoid in the category of endofunctors" is kind of a meme among non-Haskell developers. Personally, I think Haskell is a very interesting language. The mathematical jargon, however, is impenetrable, and this particular expression is kind of the poster child. I'mma go look at Erlang if I want my functional language fix without making my head hurt, thank ye very much.
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.