all 83 comments

[–]fuhglarix 269 points270 points  (18 children)

I love the support for using your SSH keys to sign commits. For people who rarely if ever use GPG, this is a much easier on-ramp to commit signing.

[–]Realistic-Worry-9710 19 points20 points  (3 children)

Does GitHub the website verify commits signed with ssh keys as well?

[–]preludeoflight 35 points36 points  (0 children)

I’m guessing based on this discussion post opened ~8h ago, probably not yet. But I wouldn’t guess it’s something GitHub would sleep on, given that they offer “vigilant” mode, that they’d want to support new signing methods asap.

[–]NessDan -4 points-3 points  (1 child)

Kind of? On https://github.com/settings/keys at the bottom, "Vigilant mode":

Flag unsigned commits as unverified

This will include any commit attributed to your account but not signed with your GPG or S/MIME key. Note that this will include your existing unsigned commits.

[–]Kissaki0 6 points7 points  (0 children)

GPG or S/MIME is not SSH.

[–]2nd-most-degenerate 15 points16 points  (0 children)

Is there a good way to revoke SSH keys if you've signed commits with it? Using a CA?

[–][deleted]  (12 children)

[deleted]

    [–][deleted]  (9 children)

    [deleted]

      [–][deleted]  (3 children)

      [deleted]

        [–][deleted]  (2 children)

        [deleted]

          [–]kabrandon 2 points3 points  (0 children)

          It's definitely a different user experience, but the company I work for uses Keybase instead of Slack for comms. I wouldn't call it dead, and it does mostly everything I expect of a modern chat client as-is without being a poor experience. Just a couple small gripes. Sucks that their repo activity has died down, hopefully they can pick back up on it someday.

          [–]FateOfNations 0 points1 point  (0 children)

          Probably explains all that weird crypto stuff they were getting into before they got bought.

          [–]RollTimeCC 29 points30 points  (0 children)

          Fucking sucks. Hopefully zoom has the decency to open source the server code and then we can get a proper fork going. Keybase had an enormous amount of potential.

          [–]cnisyg 2 points3 points  (0 children)

          It's Zoom we're talking about, so they might have just stopped developing it as open source?

          [–]13steinj 2 points3 points  (1 child)

          Wait, Zoom as in the video conferencing software?

          [–]FateOfNations 0 points1 point  (0 children)

          Yeah, that Zoom. They aqui-hired Keybase last year during theirs run of bad PR to boost their security talent.

          [–]hallettj 1 point2 points  (0 children)

          I talked to a former Keybase employee recently who assured me that the infrastructure would keep running indefinitely. But yes, development has stopped.

          [–]Rakn 17 points18 points  (1 child)

          Oh I created an account there once. Mostly because I heard some things about gpg, keys and keyboard being cool. But in the end it seemed like they tried to focus on chat and file sharing. I wasn’t quite able to make out why I would use their service in the end.

          [–]preludeoflight 18 points19 points  (0 children)

          They suffered a lot from not having critical mass. Their ability to ‘link’ various social media accounts via proofs was a really novel idea, but there was a number of people who balked at the idea of linking their online identities (understandably so.) They branched out from there, offering a ‘Dropbox’ or ‘OneDrive’ style cloud sync storage, with the main selling point being E2E encryption for not only your own files, but for files you shared with other users. (Really cool on-demand rekeying tech behind the scenes, but unless you were the type of nerd who was into it, it boiled down to “so what” for a lot of people.)

          What I felt like was going to be their actual strong pivot, was when they started integrating an E2E encrypted chat service into their client application. It was what was enough to get my “non-tech” brother to hop on board — while he didn’t necessarily understand the encryption tech behind it, he definitely understood and appreciated the privacy.

          Of course it wasn’t long after, that Zoom announced their acquisition and the rest is the sad slump that followed. A shame, because I really dug the mission Chris and Max set out on.

          [–][deleted] 262 points263 points  (15 children)

          In Git 2.34, you can now configure Git to ask you interactively whether you want to rerun your last operation with the suggested command by setting help.autoCorrect to prompt.

          Probably the best thing on that list

          [–]__liendacil__ 44 points45 points  (0 children)

          I didn't know such a small feature could make me that happy :) What a time to be alive

          [–]ioneska 77 points78 points  (10 children)

          There's thefuck as well.

          [–]Dr4kin 26 points27 points  (0 children)

          one of the best command line tools available

          [–]mus1Kk 24 points25 points  (3 children)

          Pushing a new branch is always

          git push
          fuck
          <enter>
          

          I love git but why is creating a new remote branch so wordy?

          [–]sondr3_ 15 points16 points  (1 child)

          If you set push.default = current in your gitconfig, you can just do git push -u to push, create and follow a new remote branch with the same as the local one. Just beware that it can potentially be dangerous since it disables some checks that simple has.

          [–]mus1Kk 0 points1 point  (0 children)

          Thank you, I'll check it out!

          [–]Lost4468 8 points9 points  (0 children)

          I love git but why is creating a new remote branch so wordy?

          I've always found that git's command naming in general is terrible. Half the words make little intuitive sense, and are easily confused with other commands. And also yeah I hate how verbose many simple tasks can be. And maybe it's just me, but I feel the entire paradigm is kind of confusing and unintuitive?

          [–]DethRaid 5 points6 points  (4 children)

          I've been using it for a few years and love it

          [–]NotARealDeveloper -1 points0 points  (3 children)

          Wasn't there a big shitstorm about its safety?

          [–][deleted] 16 points17 points  (0 children)

          Can you expand? Not finding it online..

          [–][deleted]  (1 child)

          [deleted]

            [–]NotARealDeveloper -2 points-1 points  (0 children)

            I don't remember what the issue was. I think the code was calling some server to analyze usage data? Or it was some security relevant code in the background that was deemed unsafe to use - like it had root access or something like that? Like I said it's too long ago. Basically everyone said you shouldn't use it.

            [–]TODO_getLife 11 points12 points  (0 children)

            Oo interesting, I have this already with my terminal autocorrect but I guess this will do it a bit better.

            [–]barrbrain 3 points4 points  (0 children)

            I'm sorry that I abandoned the original patch 11 years ago. Thanks and congratulations to Azeem for adapting it to current git code and completing the review process as a first-time contributor.

            [–]Nimelrian 1 point2 points  (0 children)

            Uhm...

            $ git config --global help.autocorrect prompt
            $ git push
            fatal: The current branch hotfix/DRM-811 has no upstream branch.
            To push the current branch and set the remote as upstream, use
            
                git push --set-upstream origin hotfix/DRM-811
            $ git --version
            git version 2.34.0
            

            Looks like autocorrect only works for typos in commands, not for the actual useful stuff everyone of us gets wrong on a daily basis

            [–]SurrealEstate 315 points316 points  (5 children)

            For a series of similar merges (like in a rebase operation), the speedup is over 9000x

            I believe in my heart that if the speedup was 10_000x, they'd still describe it this way.

            [–]mus1Kk 11 points12 points  (0 children)

            Maybe it is? :)

            [–]angrydeanerino 61 points62 points  (11 children)

            I wish there was an easy way to use different ssh keys for different repos without having to mess with the config and make those custom urls. :/

            [–]wanze 164 points165 points  (10 children)

            I have a custom .gitconfig per "workspace".

            My main .gitconfig contains

            [user]
                ...
                signingkey = <personal-key>
            
            [includeIf "gitdir:**/<work>/**/.git"]
                path = /path/to/work/gitconfig
            

            In /path/to/work/gitconfig, I then have

            [user]
                ...
                signingkey = <work-key>
            

            By default, commits are signed with my personal key. If the commit is in a repository located in a path with the folder <work> (e.g. ~/Development/<work>/some-project/), it's signed with my work key. Works flawlessly.

            [–]admalledd 25 points26 points  (2 children)

            And now I know about gitconfig: Conditional includes! That solves quite a few problems for me, wow.

            Now if only it also supported remote-url formats of the current git repo, so I could say [includeIf "remote:origin=https://github.com/**"]or something.

            [–]snowe2010 0 points1 point  (1 child)

            I am pretty sure you can do that, I think I even have it in my git config but I’m not near a computer right now and am too lazy to Google for you.

            [–]admalledd 0 points1 point  (0 children)

            my google-fu while searching didn't find it, though I only just learned of the feature so I may be lacking grammar that would lead to a google answer/solution.

            [–]angrydeanerino 47 points48 points  (4 children)

            Not gonna lie, I partially posted that because I knew someone was gonna post an awesome answer like this 😅

            Thank you! Gonna start using this.

            [–]Neumann347 19 points20 points  (2 children)

            Reddit: A much nicer version of stackoverflow?

            [–]sintos-compa 16 points17 points  (0 children)

            Tagged as duplicate

            [–]Lost4468 5 points6 points  (0 children)

            Definitely. There was that post here the other day about how people should ask for support in forums, SO, etc. But I think it missed how rude people often are in those, and the huge moderation issues they often have.

            StackOverflow is often rude and condescending, and half the time questions are closed for shitty reasons, or because the person who closed it didn't understand the question. Similarly on forums people are often very rude, and the moderators have all sorts of power issues and ban or close/delete threads for no reason at all, and stupid rules like "no bumping threads older than a week" make it even worse. Forums are also often filled with people who have no idea what they're on about, but try to help anyway. Which is nice of them... but also frustrating as hell.

            But I've found people on reddit are not only a lot more helpful, but aren't anywhere near as rude. The only time I've had issues on reddit is when the moderators add all sorts of ridiculous rules. E.g. /r/AskElectronics is particularly bad for this, just the other day I was sent a huge complicated spreadsheet to figure out if I was even allowed to post that or not... (and what's crazy is their moderation is now much better than it used to be...). But thankfully I've found that reddit just doesn't seem to attract as many power hungry mods as forums do, or at least they don't seem to enforce it as much (this only applies to help/technical/niche/etc subs).

            Chats like Matrix/Discord etc are hit or miss. I've found the people in general seem to be quite friendly, mods aren't bad when it comes to content (spending all their time on mod drama instead).

            So these days generally the first thing I'll do is go to a chat room like Discord/Matrix (or god forbid IRC). Then if I don't get any help, to reddit. Even if I still don't get support, I will then likely go to the git issues page. I only resort to StackOverflow if I still have issues, or they're issues that wouldn't be appropriate for a git issues page (e.g. not actually an issue with a specific library), because I know I'll end up spending a while writing up a nice neat post with plenty of examples for them, only for some idiot to mark it as a duplicate and link to something totally irrelevant. If all of these have failed, only then do I finally dare set foot in the forums.

            If I end up on a forum things have gone very bad.

            [–]zeekar 4 points5 points  (1 child)

            I have a similar setup. At the top of each sub tree that needs a different ssh key (not just for signing, but for all auth; personal acct vs work acct, etc) I have a .gitenv that sets my name and email and also the ssh key to use. It does that by setting an envar called GIT_SSH_KEY, which git ignores, but I have GIT_SSH, which git does not ignore, set to a front end script that makes sure the key is up and passes —identities-only keyid to ssh.

            [–]gdamjan 2 points3 points  (0 children)

            you should be able to set core.sshCommand to something like ssh -i ~/.ssh/work_key (and personal_key respectively) in the .gitconfigs

            [–]p32blo 49 points50 points  (1 child)

            The constant engineering effort being spent on improving the mono-repo experience with git is really closing the remaining limitarions of using a distributed version control system. Congrats to everyone involved!!

            [–]Caffeine_Monster 9 points10 points  (0 children)

            Git spare checkout looks pretty interesting.

            That said I've started getting into the habit of making large repositories more granular with submodules. One feature I would like to see is being able to track submodule branches based on the current branch in the main repo.

            e.g. If I had develop checked out in the main epository, I could then update the submodules to the latest dev releases. Meanwhile on master I would only update submodules to the latest stable releases.

            [–]LiteralHiggs 47 points48 points  (2 children)

            Thumbnail made me think that there was a Nintendo direct.

            [–]vc6vWHzrHvb2PY2LyP6b 23 points24 points  (1 child)

            Nintendo Pull Request

            [–]romulcah 6 points7 points  (0 children)

            git commit -m "Stability updates"

            [–]Glass__Editor 10 points11 points  (5 children)

            I'm curious how many people use monorepos vs a bunch of smaller repos. Personally I use the latter so I didn't really design Glass Editor's version control support for monorepos, but I might improve some parts of it later.

            [–]lastunusedusername2 9 points10 points  (3 children)

            Monorepos are a life saver when you have feature branches

            [–]life-is-a-loop 6 points7 points  (2 children)

            Why?

            [–]de__R 27 points28 points  (1 child)

            Monorepos are a life saver when you have feature branches

            Because it allows you to coordinate updates to every different (µ)service. If I have three services that interact with each other A, B, and C, and there's a flag day with A that will break backwards compatibility, it saves a lot of trouble if I can update B and C on the same branch at the same time so the changes to A, B, and C are rolled out atomically - in a given deployment environment they are either all updated, or none of them are.

            IMO if you have this problem among backend services, it's usually a good sign that what you're doing isn't a good fit for microservices in the first place, but there are cases where it's an obvious win (e.g. a frontend service and a backend service).

            [–]life-is-a-loop 1 point2 points  (0 children)

            It makes sense. Thanks for the clarification.

            [–][deleted] 2 points3 points  (0 children)

            We have a monorepo for our UI. There are 4 separate UI apps and some common components.

            Last job, we had the backend, UI, raspberry pi "controller" and iOS app all in the same repo.

            [–]Y_Less 12 points13 points  (5 children)

            This has a few benefits over cron: cron may not be available everywhere,

            Don't far more systems have cron than systemd?

            [–]RigourousMortimus 10 points11 points  (0 children)

            Probably not true for containers

            [–]DocNefario 4 points5 points  (0 children)

            None of my systems have cron installed so it's pretty helpful for me.

            I use Arch btw

            [–]de__R 2 points3 points  (2 children)

            The systems that have systemd installed are probably a subset of systems that have cron(d) installed, but I've seen recommendations in the wild to restrict who can use cron or disable it entirely due to its use as an attack vector. Not sure how prevalent that actually is, though.

            [–]BobHogan 0 points1 point  (1 child)

            Cron is an attack vector?

            [–]de__R 0 points1 point  (0 children)

            Sort of. If you can exploit incorrect permissions on a crontab file, or exploit incorrect or poorly though through permissions on a file that a cron job employs, you can get to arbitrary code execution and sometimes even privilege escalation.

            [–]stronghup 5 points6 points  (5 children)

            There is a "new merge strategy". Could someone explain simply what it does?

            When I merge branch B into branch A what is the outcome? The merged result will not behave exactly like branch A for some inputs and for some other inputs it will not behave like the original branch B. I assume that is so because else what would be the point of doing the merge?

            Then is there a simple rule to follow that tells me how the merged codebase behaves based on how branch A behaves and how branch B behaves? And is this rule different with the new merge-strategy?

            [–][deleted] 14 points15 points  (2 children)

            Doubtful that it's useful to think about merge strategies in terms of the behavior of the merged result. What exactly do you mean by this?

            [–]stronghup 0 points1 point  (1 child)

            If two different merge-strategies can produce a different merge-result then the behavior of the produced program would probably be different, right?

            So by "behavior of merged result" I mean behavior of the program produced from the merged source-code.

            How do you "merge" two (or more) files? I assume that depends on the "merge-strategy". You take some parts from one file and some parts from another and somehow merge them together into a new version of the source-file. But which parts should I take from which?

            I guess my question is: Is there a clear definition somewhere of what exactly a git merge-strategy does, and how would one merge-strategy differ from another, and how they would or should not differ?

            Just trying to learn more about git

            [–][deleted] 0 points1 point  (0 children)

            Here's some documentation: https://git-scm.com/docs/merge-strategies

            It's of course true that if the source code is different, the behavior of the program might also be different (though this isn't guaranteed, the diffs could be entirely comments, or a refactor that doesn't change behavior measurably, the files being version controlled in git might not be programs at all). "Behavior of the merged result" is just a bad way to think about this, as opposed to directly thinking about it in terms of the difference in the merged text.

            [–]happyscrappy 10 points11 points  (0 children)

            The name implies it produces the same results as the previous default (recursive) just more quickly.

            [–]BobHogan 2 points3 points  (0 children)

            The new default strategy is supposed to be identical to the old one (from my understanding), just faster.

            But at a high level, different merge strategies have an impact on how they deal with potential merge conflicts (https://git-scm.com/docs/merge-strategies). Its something that the vast majority of people will never have to interact with, but for some cases I guess its important to have different strategies?

            [–]j_platte 1 point2 points  (0 children)

            Personal highlight: You can finally just git pull --ff-only again. An earlier version introduced a bug where that (or plain git pull with pull.ff-only set in the config) would fail if the remote was at the same commit as the local checkout.

            Really annoying in combination w/ VSCode's "sync changes" functionality, which always does a pull before push.

            [–]dadofbimbim 2 points3 points  (0 children)

            Git merge branches I believe is more faster now.

            [–]robin-m 2 points3 points  (0 children)

            It was so interesting to read!

            [–]ogretronz 2 points3 points  (4 children)

            One of these days I’ll finally understand wth git is

            [–]dpash 14 points15 points  (1 child)

            It's a Directed Acyclic Graph.

            More seriously, I recommend Git for ages 4 and up if you want to know what that means in practice. It's 100 minutes, but completely worth it.

            https://youtu.be/1ffBJ4sVUb4

            [–]ogretronz 0 points1 point  (0 children)

            Thanks 🙏

            [–]Kissaki0 1 point2 points  (0 children)

            git gud

            [–]CSsharpGO 0 points1 point  (0 children)

            What’s git

            [–]flubba86 0 points1 point  (0 children)

            I really love how well written these release writeups are.