Hacker News Reader

Comment by verandaguy | Hacker News Reader

I mean, it's the shortest _possible_ pull request (since I don't think you can make a git diff of zero bytes, barring some weird quirk), but also probably has the highest PR description : PR diff length ratio of any PR I've seen.

View on HN

Working in embedded, I've seen commits that changed a single bit with pages and pages of background explanation :D

I think file mode changes (eg 0644 -> 0755 to fix a script not running) could be smaller

`git commit --allow-empty -m 'empty commit'` will do.

That won't show up in diffs though, while this one does show up albeit it's VERY hard to spot the actual difference, as the different is a space with zero width.

Rejected, please don't commit code in a broken state.

You can't commit code from New Jersey?

Given that a BOM is three bytes, I don’t really agree that it’s the shortest. How about replacing a CRLF by LF? That one is invisible in many contexts as well.

…or removing a trailing LF at the end of a file where the last line is non-empty.

Depends on whether you consider `git commit --allow-empty` a weird quirk ... I guess it would be reasonable to do so ;).

What's the purpose of this? I can think of ways to use/abuse it, but there has to be a specific reason that it was added as a feature to git.

I see `--allow-empty` in git tutorials all the time, to demonstrate the concept of a commit. I'm not sure when you'd reach for it in a real repo though

The most obvious reason not involving automated systems is to create a repo’s initial ref. This can be useful on teams who are super strict about review process and git history.

Once you account for automated systems, many other reasons can arise. Not just the “trigger CI” case mentioned in another comment, triggering builds or processes based on remote content the code accesses, or generating something either random or seeded by the commit hash/timestamp/message/etc.

It can even be a Homer Simpson-style drinking bird button press, so finished software doesn’t get mistaken for abandoned.

Probably whole worlds of things I haven’t imagined because I don’t use git hooks or submodules.

git commit --allow-empty -m "trigger CI job"

Nice. I used to just add a BOM at the beginning of a random line to accomplish that.

I think this post is a good reason not to do that ;)

I use it to trigger CI/CD. And for example, when upgrading Heroku's dyno stack, when is applied on next deployment.

    heroku stack:set heroku-22
    git commit -m 'upgrade to heroku-22 stack' --allow-empty
    git push heroku master

Maybe so you can make an empty initial commit and push it to a remote like Github as a placeholder? Or a lazy way to trigger a CI job when you're gonna squash and cleanup later.

I guess conceptually you could use it to represent "I started from nothing."

I've found it useful when interactively rebasing a series of commits to make a nice PR. The code moved to a different commit, but I didn't want to lose the message.

For those of us who start projects often, but never finish them:

    git commit --allow-empty -m "Initial commit."

I use it extensively for entire PR based development; that way all the code that ended up in the repo has had multiple eyes (and an opportunity to comment) upon it

    git commit --allow-empty -m "initial"
    git push -u origin HEAD
    git checkout -b first-pr
    # type-y type-y

The most common reason I see it is to create the initial commit of a repo. This is useful both so you have something to push to a remote, PR against, and because several git commands (most notably rebase variants) need weird switches (eg --root) if you _don't_ have an empty initial commit to refer to instead.

Reply on news.ycombinator.com