Is there any reason besides merge commits ending up in history to not do this with merges instead? ie merge main into feature-1, then feature-1 into feature-2.
Sounds like using --update-refs would let you do all that in a single operation, but you still need to force-push and don't maintain an explicit merge/conflict resolution history, both of which could be considered sub-optimal for collaborative scenarios.
Nice web ui aside, if I'm not mistaken youtube-dl already supports this kind of usage. You can `youtube-dl --download-archive archive.txt https://youtu.be/your-playlist` and it'll keep track in the archive.txt of everything it's already downloaded. Supplement with authentication options as necessary, set up a cronjob, done.
I appreciate the "just the current day" angle, but would gently remind about timezones. A 24-hour rotation isn't super friendly towards people who are online at the edges of that window. You might consider keeping a viewable archive of yesterday, just so one always has time to go back and see comments/replies.
> Black to move, and in the final position, the pawn at h4 can be captured en-passant.
> They're all legal.
But then, looking at the final position[1], black is in check by the knight on b2. If white's pawn can be captured en passant, this implies the knight was not the most recent move, so the black king was in check on the previous turn as well.
It's obviously not legal to remain in check. What am I missing?
Been using a Gergo for well over a year now. I think I might own the first one that was made with the low-profile Kailh Choc switches.
I can't imagine going back to anything else. The low profile, combined with custom key layout (workman, modifiers on homerows, etc) has done wonders for my RSI. Of course, tho "wow, what's that"-factor is also fun.
The language itself is not coupled to the PKI. The PKI ("azimuth") is implemented as a contract on Ethereum. The OS ("arvo"), implemented in the language ("hoon"), has a networking module that respects the PKI, but also affords for (practically) infinite not-PKI-registered identities.
Urbit does not run on or via blockchain. Its PKI lives on a blockchain. Urbit itself doesn't care about how packets get from A to B. You run it on a machine you own.
Social communications yes, especially on smaller/more "local" scales.
Sounds like using --update-refs would let you do all that in a single operation, but you still need to force-push and don't maintain an explicit merge/conflict resolution history, both of which could be considered sub-optimal for collaborative scenarios.