$ git show d85c9944c55fb38f4eae149979a0f680ea125ecb | wc -l
11067
$
From `man git-log`: "Note that unless one of --diff-merges variants (including short -m, -c, and --cc options) is explicitly given, merge commits will not show a diff, even if a diff format like --patch is selected, nor will they match search options like -S. The exception is when --first-parent is in use, in which case first-parent is the default format."
Presumably the author would have been happier using the -m-flag in addition to -p.
And that's one of the reasons why I advocate against merges in the codebase on every project I work for and in every HN thread where the topic of merges is mentioned.
That might reveal the depths of my ignorance of Git, but how do you manage moving changes from one branch to the other if you don't use merge? Edit: continuing to read the discussion, it seems it's rebase? I have some reading to do
i use rebase frequently, but i never remember which direction the operation goes in. do you need to checkout the source branch or target branch? truly, it is unknowable. my workflow is to type `man git rebase` and hit space to page through the manual until the first ascii tree surgery diagram appears. then i stare at it until i remember that i need to have checked out my feature branch and am meant to type `git rebase main`. i have trained myself to read the man page every time, perform the operation correctly, then immediately forget.
I use "branch.autosetuprebase=local" and/or --set-upstream-to ; then I can just type "git rebase" while on the thing I want rebased and not have to think about it. (Useful in the gerrit workflow which kind of forces you to have stacks of rebased changes)
The approach described on that site doesn't strictly rule out "git merge", but it emphasises short-lived branches and unidirectional commit flow. If you do things that way you find you just don't really need merges. The next step is to think "merges are rarely useful and sometimes dangerous, so let's just avoid them completely".
Gotta say, I find that horrifying. What about peer reviews? What about breaking up a change into smaller commits, none of which make sense until they're all together (changing the signature of a method, then changing the places that call that method, etc)?
It's worth noting that is mentions that work on a branch and the use of PRs are acceptable, but... the two statements appear to contradict each other. Why say "only do x" and "do thing that isn't x" on the same page?
I can’t find the quoted text in the parent post or article, but as someone who’s fought the short-lived branches crusade in the past (in favor of it) I’ll do my best to answer the criticism you raise :-)
> What about breaking up a change into smaller commits, none of which make sense until they're all together (changing the signature of a method, then changing the places that call that method, etc)?
The general-form solution to this is to make a three-part change: 1. add the new code, 2. migrate all the callers, 3. delete the old code in three separate PRs (or more, if migrating the callers takes several PRs, or some of the old code can be deleted earlier than the rest). I believe arbitrarily large changes can be made this way, and as your origination grows, eventually all large changes _have_ to be made this way.
Isn’t that a lot of extra work? IME it’s a lot less work (and risk!) than resolving a massive merge conflict.
The problems with long-lived branches all derive from the basic problem that eventually the complexity of maintaining two parallel implementations affects the work of everyone at the company.
New person joins before `Big_Refactoring` is merged? You’re either onboarding them twice into two branches, or they’re getting nothing done while they wait for the merge so they don’t have to learn a bunch of code that’s going away soon anyway.
Someone else wants to make a significant change? They either carefully patch each PR into both branches, or they decide “screw it” and do all their work in `Big_Refactoring` anyway, diverging the branches _even more_ and creating more risk in the ultimate merge and more of an incentive for others to start developing in `Big_Refactoring` and make the problem even worse. Soon the feature branch is a de facto main with failing tests while there’s incredible pressure to just ram the merge through so all these changes can go out.
The only way to make it work is to demand that only one person develop in `Big_Refactoring` and everybody else manually cherry-pick their changes into both branches (which quickly just means implementing them twice). IME everyone finds this so annoying that small branches, feature flags, and three-part changes (which makes code sharing between the old and new implementations much easier) become broadly preferred anyway.
As far as PRs, I can’t speak to the linked article, but everywhere I’ve worked that implemented short-lived branches still did PR review. But the PRs had to be small and quick to review (which IME actually helps catch bugs too)
> Isn’t that a lot of extra work? IME it’s a lot less work (and risk!) than resolving a massive merge conflict.
>
> The problems with long-lived branches all derive from the basic problem that eventually the complexity of maintaining two parallel implementations affects the work of everyone at the company.
This seems to imply that there's a choice between A) committing to the main branch, and B) long lived branches. I always work on branches, almost always with multiple commits, and then merge it into the main development branch once the feature is complete. I almost never have to deal with complicated merge conflicts.
That being said, you're talking about short lived branches. The article talked about committing directly in the main trunk/master branch; which is what horrified me.
Sweden has never had secret ballot. The “Valmyndigheten” election authority themselves have criticized the lack of secrecy and general chaos with Sweden’s ballots. But what do they know? They only administer the elections.
Swedes have a highly developed superiority complex and ability to perform mental gymnastics about the flaws of their country and ways of doing things. No sane person from any other country in the world would consider a system where voters must, in public and under the active scrutiny of other voters and local election officials (who are themselves politicians and party members) pick ballots for the party you intend to vote for and then bring it into the “secret” booth. Any child or idiot can see that’s not secret other than in the most distorted and disingenuous sense of the word.
The government agency was tasked with finding ways of improving their work. One of the things they recommended was for the selection of ballots to be hidden, which has been implemented since then.
It will probably have a negative effect on the ability for smaller parties to get started.
This is the most common counter, but it doesn’t change the fact that the ballot is not secret. Again, you’re picking ballots in public and under the active scrutiny of other voters and election officials, and there is a strong and palpable disincentive to pick ballots from the “wrong” parties, and a strong and palpable incentive for showing your neighbors and friends you pick only the correct ballots before going into the booth. Smaller parties have to come up with nationwide ballots themselves, which is often impossible. People can and do also vandalize, hide, throw away and illegally modify the ballots such that voters who show up can not vote according to their wishes. I have personally experienced TWICE having to ask the election officials out loud to restock the ballots for the party I intended to vote for, and so have countless others. I could go on. These are all known problems that the election authority themselves have pointed out should be rectified, but they never will be, because the system is working as intended. (discouraging votes for the wrong parties)
Yeah, and blank ones if you want to write down the party of your choice. You could bring your own ballot if you so choose, or vote pretty much anywhere else than were you live during a ~ three week long period.
yeah... or you could just implement secret ballot like all sane countries have
> blank ones if you want to write down the party of your choice
this can and does risk resulting in the vote not being counted (due to alleged illegibility, a tiny spelling error or whatever)
> You could bring your own ballot if you so choose
same thing, your own ballot could be considered illegitimate + even in the best case that you obtain a real lawful ballot, only a tiny fraction of people are willing and able to go through the trouble of doing so + again, by requesting a ballot, secrecy is out the window
> or vote pretty much anywhere else than were you live during a ~ three week long period
the suggestions just keep getting more and more ridiculous - no one should have to do any of this! everyone should be able to just rock up and vote with secrecy preserved, without having to prepare or use all these hacks
As per my prior comment directed at you, you have been reminded that the improvement you asked for had been implemented into law.
As per the same comment, the situation for new parties have thereby become worse. You are sure to have experienced the same problems we experienced when getting the Pirate party into parliament when you got the Sweden Democrats through the system.
Which country has "secret ballot" then ? Cause what you described as imperfect is the system that is present in all countries I've ever been in, and I've been in the majority of western europe...
Almost all actual democracies have secret ballot? There’s any number of ways to ensure secrecy is preserved at all times by default. (unlike in Sweden, where virtually no votes are secret because it requires hacking the process)
I am not familiar with zsh, but is it really interpreted by zsh? Because the script has #!/usr/bin/env bash in its shebang, isn't it executed by bash on your system, even if launched from zsh?
The `~` path (and `cd` with no arguments, to get there) are also part of the prime real estate. It's as if these polluters think you'll enjoy accessing their stuff via `~/<tab>` which might or might not be true.
Polluters probably assume you'll never access anything at all except through dedicated apps, and bookmarks. In my case it's mostly true but it's still icky and ugly to see a crowded home dir.
Yeah, but that is still one application. You might come fr enough with CDPATH and configuring .inputrc to do something smart with ^m and the %-character (for the root of your document folder).
If it will be enough, I don't know. It might be enough for some, but it is still something which can be done without getting the maintainers of openssh to agree with the idea of a clean ~.
If you delete one folder the file $HOME/.config/user-dirs.dirs will be updated sooner or later, and point to $HOME/ and the icon will not be restored by recreating any folder.
And that is why there is different types of subkeys, which you are told about when generating the keys, and every "getting started" guide I've found. If you don't want to receive encrypted emails, don't share a subkey for encrypting email?
Sure, but there are things for encryption other than email. Publishing an encryption key does not imply that emails sent to me should be encrypted to that key.
Please not that the authors are Norwegian at a Norwegian university, and the first citation are "KVANTEFYSIKKENS UTVIKLING
i fysikklærebøker, vitenskapshistorien og undervisning" by Reidun Renstrøm at the University of Oslo, all proclaiming the myth being perversive.
I would be careful proclaiming this being some kind of American phenomenon.
Or you could just import weasyprint and readability in python!
Which is pretty much what OP did, with a few nice additions like nice output and some custom css and fonts. Which is nice and OP hope brings value to people.
If you add a few printf:s and include a nice template for pandoc* it would be more along the same thing.
*) Neither pandoc, wkhtmlpdf or weasyprint have (in my opinion) bad default templates.
Prefixing your scripts is an awesome tips. A colleague told me he prefixed all his commands with ',' and I've started to do the same. '_' might clash with 'hidden'(?) shell expansions etc.
Sadly git doesn't allow for aliases with an comma-prefix, so all git aliases starts with a dot.
Presumably the author would have been happier using the -m-flag in addition to -p.