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.
They meant merging the other way, i.e. merging the new changes from main into the stacked feature branches.
This is functionally the same as rebasing, except that the new changes show up at the tip of the commit chain rather than the base. And because it doesn't rewrite history you don't need to force-push.
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.
It's even simpler than that, just give youtube-dl the channel name and it will download all videos skipping any that already exists in your current directory.
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.
Thanks for your feedback, I just thought about the timezones last night. I will pass the client's date while fetching the artwork of the day so that everyone get the full 24h lapse.
For the read only archives, I can see from the comments on HN that it has been requested a couple of times but some people also seem to enjoy the "just the current day" angle as well so I'll have to decide on that.
> 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?
I'll have to make some changes to my README.
Meanwhile, congratulations on spotting the error. And I'll be sure to mention you in the eventual publication.
This underscores the need to back up my classification with proof games...
But just today github user @mcdallas found another position misclassfied as legal [1], so the two misjudgements cancel out and the original 538 count currently still stands. Lovely:-)
Being in check means it’s your move and the pieces are positioned so that if it was your opponent’s move they could capture your king. So, to “remain in check” would mean to make a move which still allows your opponent to capture your king. If this were allowed the opponent would just capture your king and you would lose. Instead, the rules of chess require you to “get out of check”, i.e. make a move which prevents your opponent from capturing your king. If there is no such move you are said to be in “checkmate” and you lose.
It's a good question as most games, including chess have few rules about making otherwise legal moves illegal just because they might be suboptimal. In novice games the other player might not even realize they can win, so it being illegal to stay in check is an oddity but one that's actually in the rules.
As far as I’m aware, the only game-theory difference between chess and a variant of chess
where moving into check is legal, is that stalemate exists. Otherwise the “can’t move into check” rule is basically useless.
It's funny-- except for Tenoke all the responses so far boil down to essentially this.
I'll try again.
Assume an alternate reality where this incredibly important rule doesn't exist. In it, the other player simply takes the king on the next turn from a neophyte who didn't realize they are still in check.
What bad things would happen as a result of the non-existence of the gratuitous rule?
And don't just speculate based on the zero cost of posting on HN. Give me the real reason based on the history of the creation of chess rules and/or the documented behavior of real chess players in history.
> Assume an alternate reality where this incredibly important rule doesn't exist. In it, the other player simply takes the king on the next turn from a neophyte who didn't realize they are still in check.
This is not merely an alternate reality; this is effectively the reality of blitz chess, where capturing the king is a way of claiming victory by declaring that the opponent made an illegal move when they didn't move out of check. In blitz chess you do not have the right to correct illegal moves after the opponent points them out.
If the penalty for the specific illegal move of not getting oneself out of check is to lose the game, what could the practical significance of the rule possibly be?
The other respondent is claiming that chess would become a game of "gotcha," as if the rule somehow prevents chess players from faking injuries to distract the chess ref and get free moves.
In regular chess, the rule just helps a player avoid one particular kind of blunder. Basically, it was arbitrarily decided that game records should never have king captures in them.
I would agree that makes it a poor excuse for a rule.
There is no immediate penalty, normally the opponent notices the illegal move and points it out, and the player has to undo the illegal move and continue with a legal move. Now if the player disobeys, then the opponent is able to declare the game forfeit.
An interesting edge case is if the opponent does not notice the illegal move. See FIDE for details.
Chess is a politically-themed wargame featuring monarchy. The King, being top kick, makes the rules of the land. Of course the King would enact such a rule that makes putting/leaving him in danger illegal.
Think about actual, medieval monarchs in their castles, holding literal absolute power over everyone. If someone were to invent a board game featuring a King, and the King were to be made aware that you moved him into danger and got him captured, he might have your head.
I feel as if I'm asking something fundamental that hasn't been considered by insiders. As if I asked music afficionados why Beethoven's Appassionata Sonata couldn't be performed in F-sharp minor and the response is something like, "Because arbitrarily changing the keys of sonatas would make a travesty of classical music, and performing the piece in F minor supports the preferences of the people who enjoy listening to classical music."
I don't know the history, but it's consistent with all the other rules, e.g. checkmate stops the game one move before the king is captured, stalemate occurs if the king would have to open himself up to capture, etc.
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.
I'm putting the finishing touches on my first one and should be able to release it over the next couple of weeks. It's the "Exercier-Reglement der K&K Cavallerie" from 1898, Habsburg-Austria's "answer" to the more well-known Prussian army riding instructions from 1882.
I can post a link here when it's ready, in case you're interested (just bookmark this thread). -- It will be in German, though. (Maybe I'll get into the business of translating one day, but not as of now).
I also have a second one in the pipeline, which is the aforementioned Prussian work (which eventually developed into the even more well-known HDV12 in its edition from 1937 that had a great deal of influence on the kind of dressage we see today).
When I'm done with that, I've already collected the source material on the British "Cavalry Drill", also of 1898. That one will be in English, obviously, but have no clue on when it might be ready.
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.