> (they no longer teach that in "computers" at school, by the way, iPads only)

I swear, some decisionmakers deserve a brutal punch in their face. I don't even care anymore about being civil in such matters.

Has that abomination of a title also been generated by one?

Laughed hard on that :D Sorry if the wording is not great, I'm neither a native English speaker nor good at copy-writing. I worry the title can't be changed anymore anyway

An admin might be willing to change it (: Could be changed to "TL;DR AI, a ..."

Changed now (more at https://news.ycombinator.com/item?id=40214624).

"But it is littering the commit history with useless commits!" is what I always hear

And the best answer is: "Why do you do useless commits?".

With `git amend` and `git fixup` you can arrange your commits to be clean, properly documented and self explanatory (and maybe atomic but that's a little harder). It takes a little time but it is hugely beneficial to code reviews and bug investigation.

Some people however see using features like amend, squash, and force push as potentially destructive actions in the hands of a novice, which can lead to loss of not only the author's work but also other people's. Using merge almost never results in any sort of loss and is easier to work with for those who still don't quite understand the risks.

You are associating the use of `amend` and `fixup` with force push. It's perfectly fine to rework your commit history locally and even force push to your own local branch. It should never be possible (except to people administrating your repo) to force-push to any public or even shared branch.

Nobody should be able to force-push to master (or any public branch) except on specific occasion. In that case, someone is authorized, performs their specific action and then get de-authorized.

This is pretty basic.

"Force push" is something that should be restricted to a very few senior people anyway; once you do that, you can't rewrite shared history any more and a lot of the worries go away.

This is a great way to get me to clutter the shared repo with throwaway branches that I’ll later replace (deleting the old one—if you let me).

This is fine! This is a normal part of several popular git workflows. After all, a branch is just a pointer to a commit.

(Our workplace has a mix of github flow, which is one branch per PR: https://docs.github.com/en/get-started/using-github/github-f... ; Atlassian Gitflow https://www.atlassian.com/git/tutorials/comparing-workflows/... ; and the completely different Gerrit flow which ends up very rebase and amend heavy: https://gerrit-review.googlesource.com/Documentation/intro-g... )

I thought you meant blocking all force-push. Shared branches should absolutely be protected (with an “in case of emergency, break glass” option)

Meanwhile the biggest issues I actually see in novices are when their IDE presents them with buttons that don't coincide with a single version control action (can you guess what "sync repo" will do?) and using those puts their checkout into a weird state.

Usually when using the commands directly they're more careful, but have the mindset "an IDE wouldn't intentionally break something so this button must be safe to click".

Custom terms on top of git is a bafflingly bad decision.

IDEs in particular should expose the details all the time, and show the command that's being run, so it can teach people passively instead of misleading them and leaving them stuck when it breaks.

totally agree here. commits are not for saving "your-current-work". Its about marking a definite step of change in the realm of the project itself.

making commits atomic is harder because we tend to just write code, without first breaking up the requirement into atomic pieces

Commits are for saving your current work. Commit early, commit often. Just clean them up when you're done!

Don't push half-baked work on other people! You waste their compute cycles needlessly, from now until the end of time.

I sometimes wish git supported hierarchical commits.

I.e., git can retain two representations of a sequence of commits: the original sequence, and also a larger commit that (a) produces the exact same code change as the sequence, and (b) has its own commit message.

Isn't that what a branch and a merge commit do?

Yep, as long as you use "--no-ff" to force a merge commit (and presumably edit the merge commit message instead of just using the default).

For viewing history you can use "git log --first-parent" to view only those merge commits, which should satisfy the people who love a linear history, without actually losing the intermediate commits.

I have entertained similar thoughts, but then on the other hand people already, and with some righteousness, criticize git for being too complex. It also requires careful assessment where the wormhole ends, how many levels of grouped commits should exist.

Then I remember that I have enough trouble getting a few dozen people together to write well formed and understandable commit messages for one level of commit messages alone. This scheme would require people to extend more energy on constructing commits which is at best something very few care about.

Then there are tickets and other corresponding information, but they could rot for all I care, as they so often do, unless a decent commit log is in place.

FWIW, Mercurial has this, and calls it changeset evolution:

https://www.mercurial-scm.org/doc/evolution/

Merge does that, yes, hence the preference for rebase flows.

(I'm surprised this got a downvote when that's how we got here: a situation in which a change was ""hidden"" in a merge commit that would have been explicit in a rebase workflow)

Angry fruit salad

Yeah but it is fire.

Just set up a simple VPN with nginx and upload the page, done. Stop overthinking and overengineering everthing to smithereens.

True, was also considering this. Just thought having a CDN would be useful at some points (e.g. to compress/resize images, generate source sets of images automatically)

We have something similar in Switzerland called FairTiq

Technically, there was DSSSL already though. It is missed dearly.

Whoa, that was unexpected.

But technically, DSSSL (OpenJade) was used to render pages to print/PDF and never ran as part of a browser stack (unless I've overlooked some stubborn Schemer implementing it in JS or emscripten or sth; but don't tell HN's Lisp fraction to given them ideas ...) Unlike SGML itself, which is mentioned in TBL's docs as the basis for HTML markup. Btw SGML does have its own styling language in link processes which basically just re-uses regular attribute declaration syntax, plus has some explicit state machine representation (aka "links").

But yeah, using a Lisp derivative would've definitely prevented the syntax proliferation that is CSS, its terseness/magic, and habit of re-use of property names for different purposes as a way to sneak in complex layouting features by understated surface syntax changes.

I guess one neat feature is that every gist is actually also a git repository, but that's about it...

That is literally a bash oneliner - pipe curl into tar, and have it unpack to ~/.local/bin.