1. 24
  1. 13

    The whole blog seems to have disappeared. It also takes an extreme amount of time to load while some JS spinner is turning. I want the old web back, where this would take milliseconds to load.

    1. 9

      I was gonna make a crack or two about how slow the web was on dialup, but then I looked at this site and no, no, you’re totally right. It does a heck of a lot of work to load minimally-styled text and a few images.

      We’re sorry but frontend doesn’t work properly without JavaScript enabled. Please enable it to continue.


    2. 12

      git doesn’t have actual command to un-stage a file(s)

      git restore --staged <file(s)>


      1. 9

        Lmao the first example is so cursed

        git log --graph --abbrev-commit --decorate --all --format=format:"%C(bold blue)%h%C(reset) \ - %C(bold cyan)%aD%C(dim white) - \ %an%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n %C(white)%s%C(reset)"

        1. 5

          Urgh the curse of the tutti frutti.

          I think I’ve developed a physical aversion to cyan.

          1. 1

            Attack of the Angry Fruit Salad!

          2. 2

            That is what we have Git aliases for ;)

            1. -1

              That is what we have Git aliases for ;)

            2. 9

              git features I started using, but only after a while:

              • git pull --rebase
              • git commit --fixup <hash>
              • git rebase -i --exec=<run the testsuite>
              • git rebase --onto <ref> <hash> <ref>
              • git stash --include-untracked
              • git rebase -i --root
              1. 4

                I was really hoping git commit --fixup would be in the original post - that’s the number 1 git command I recommend to new users

                1. 3

                  What does it do?

                  1. 9

                    I usually market it as “the easy way to git commit --amend something other than the most recent commit”.

                    In more detail, git commit --fixup <ref> creates a new commit annotated to be a “fixup” commit of the given commit ref. A subsequent git rebase -i --autostach <some commit before ref> will automatically move that commit to directly after <ref> and turn it into a fixup rather than a pick, meaning it will be merged into that commit and its message will be discarded.

                    Emacs+magit users can get the whole “fixup-and-autosquash” dance in a single step with c F (magit-commit-autofixup), which gives you a git log to choose the target commit from and runs the autosquash in one go, which is one of those user experiences which genuinely feels magical the first time you try it (magit is full of them!)

                    1. 2

                      Thank you for explaining!

                    2. 1

                      I’ve written about this at https://www.jvt.me/posts/2019/01/10/git-commit-fixup/ if you fancy a bit more of a read

                    3. 2

                      also git rebase --autosquash

                  2. 4

                    Alternatively, if you’re not a CLI zealot, a good git GUI app will do all of these without you having to remember all these subcommands and flags. I read through this post looking for new stuff, but was like “OK, Fork does that … it does that too …”

                    I’m not disparaging the CLI! I know a lot of people here prefer it for everything. But if you’re not one of them, using an app for git is a real blessing.

                    1. 4

                      git worktree. Look it up.

                      1. 3

                        git doesn’t have actual command to un-stage a file(s), though. To get around this limitation…

                        Limitation, or poor UI decision? I’m guessing the latter.

                        1. 10

                          newer versions of git have git restore so I think that counts

                          1. 5

                            git reset -- filename or git reset HEAD filename do the same, tho, right? And that’s been in git for ages.

                            1. 5

                              I know, just wanted to say there is now an actual command. The article claimed there wasn’t one.

                              1. 1

                                Sometimes. If the file is already in HEAD then this works, but if it’s a newly created file I don’t think this works.

                                1. 2

                                  It definitely works with newly created files.

                            2. 4

                              The naming problem. There is, and always have been, git reset that does what OP wanted, however the “feeling” that this one command does “a lot of different things” (reset staging and reset working tree, depending on the flags) is what made people say it doesn’t have such command.

                              1. 3

                                I use tig which makes unstaging single files easy and natural, among other things

                              2. 3

                                Your blog doesn’t show up without JavaScript? But blogs are static by nature!

                                1. 1

                                  Huh? I’ve used blog software that creates dynamical views using only HTML + CSS, and I can create a static file that only contains JS.

                                  1. 2

                                    I think their point is that blogs exist primarily to display text, displaying text has never required javascript. So when a blog fails its fundamental purpose because it “needs” javascript, it’s hilariously bad.

                                2. 1

                                  Lots of nice tidbits in here, and that’s good. But let me focus on one of the items:

                                  Frankly, I think rebasing for a clean history merely has perceived benefit. I have yet to see any demonstration that it provides actual benefit. Like, with metrics, or other measurable proof. All I see is people that ask for it, and people that behave as though it makes them feel better. I don’t have any problem with that, as long as we call it what it is. A style preference.

                                  There is actually at least one tangible downside to rebasing already-pushed material: if your team works with github, then rebases reset github’s memory of people’s “time of last review”, so you can no longer [easily] avail of features like viewing the diff of “commits since last review”. Also, rebasing makes things significantly inconvenient for teammates that have local checkouts of the same branch with local changes, compared to a “merge by default” team protocol.

                                  [rebasing] makes it also easier to later look for commits that introduced some specific feature or a bug

                                  What we have is a local git hook which takes a fragment of the branch name and prepends it to the commit message. So, given a branch like FE-135--fix-dashboard-margin, it will make the commit message [FE-135] increase the horizontal margins to match new design standards . Then, when you look at the history, you see these tags, and you can even do searches, filters, etc. on these tags. We know exactly which commits were for exactly which Jira (or Trello, or Asana, or ___) card.

                                  1. 2

                                    A useful distinction to make is what type of branch you are working on. For a local feature branch that I’m working on I always rebase to one commit. For master, accept, or other shared branches one should never do that, as it messes with other people’s workfow, like you said.

                                    I think there is a benefit outside style preference to that local rebasing: it makes merges and reverts so much easier. If the merge contains dozens of half baked commits, sprinkled through the history, you are going to have a really hard time if there is a conflict, or the automatic revert on your tool misunderstood something.

                                    But even outside of that. I think there it is good practice not to add a lot of noise to the signal if you ever hope to make use of the information. That is not a style preference, that is common sense. Your local history is completely uninteresting to the rest of the team in the same sense that no-one gives a damn about how often I pressed save while I was editing a file. Would you object to adding that information to the history too?

                                    1. 2

                                      Your local history is completely uninteresting to the rest of the team in the same sense that no-one gives a damn about how often I pressed save while I was editing a file.

                                      It’s very useful if you’re doing a git bisect!

                                  2. 1

                                    I’ll add some bits.

                                    I fully agree that history is better kept linear with rebases than allowing a lot of merge commits. But sometimes when rewriting history you mess up and risk losing work. No problem, git reflog to the rescue! You’ll see the past states your working tree has been in, and once you identify the state you want to be in, you can just git reset --hard HEAD@{5}.

                                    As always, it’s best if you have a good mental model of how git works internally. Basically every branch is just an alias for some commit, and all that reset --hard does is change what commit the current branch points to. And what rebase, commit --amend etc. do is create new commits similar to old ones and update the branch pointer. The old commits are not deleted (until you run git gc and the prunable commits are old enough).

                                    Also, when you’re deep into the rebase/amend style (eg. working with Gerrit, which I highly recommend!), https://github.com/mystor/git-revise/ is an awesome tool. If you have half a dozen commits and want to amend a specific one in the middle, you just git add -p your changes, then git revise <TAB> and select the commit you want from the Zsh autocomplete menu. This is faster and more difficult to mess up than the typical rebase -i style, even with commit --fixup that does simplify things.