One of the most impressive aspects of Melon Playground is its physics system. Every action feels meaningful because small changes can lead to very different outcomes. Whether you’re connecting objects, applying pressure, or testing explosions, the results often feel unpredictable and entertaining. This makes experimentation highly addictive, as players are constantly curious to see “what happens if” they try something new.

The ragdoll physics of the characters add another layer of fun. Watching how they react to impacts, tools, and environmental hazards can be both humorous and fascinating, especially when combined with creative setups.

The user might manually git push, knowing push-to-create is a thing, but do it after git-annex init, and so annex-ignore is already set and will stay set until they git-annex push. Which they may never do.

To deal with this, when annex-ignore-auto is set, Remote.Git could check if the remote tracking branch exists. If so, unset annex-ignore-auto and annex-ignore and re-run the uuid probing.

Here's a better plan: annex-ignore remains the config, but annex-ignore-auto is set when git-annex sets annex-ignore. If the user manually sets annex-ignore, they don't set annex-ignore-auto.

Then, git-annex push can check if push-to-create happend and unset annex-ignore iff annex-ignore-auto is set.

Problem with a new config (call it annex-ignore-auto) is that users may have learned to unset annex-ignore when there was a problem that got corrected, and would need to learn to unset annex-ignore-auto instead. While git-annex push would do it for them, they might not use that.

Is this disruptive change worth it to support push-to-create? Probably. But it does make the option of checking before push and after push and unsetting annex-ignore seem more appealing.

The situation where 2 users are doing push to create of the same remote repo at the same time is very unlikely to happen. And currently what happens is that both have to unset annex-ignore. A change that makes only one of them but not the other need to unset it is not making things worse.

It could simply commit after each change. But that would bloat the git-annex branch with a lot of small commits when a lot of files are being sent to the server in one batch.

I think what probably makes sense is to detect when the p2phttp server has been idle for some amount of time, and commit then. A few seconds idle should be enough to coalesce everything done by a typical git annex push into a single git-annex branch commit.

This seems like a bug in the p2phttp server, it should not be leaving the git-annex branch uncommitted for long periods of time. It's easy enough to show that it leaves changes in the journal for a long time.

Probably we don't usually notice the bug because usually, if the p2phttp server doesn't commit the journal, the client will record the same information in the git-annex branch on its side, and push it out in the normal course of events, eg during a sync. I assume your JS client doesn't do that.

I've filed a bug: p2phttp timely journal commit

(As to the p2phttp clientuuid parameter, it is actually only used in transfer logs, which don't get into the git-annex branch. Using a made-up non-UUID there, or for that matter, using a UUID that "belongs" to someone else won't cause any real problem. (git-annex info will use the non-UUID in the "transfers in progress" display). This does not seem related to your problem.)