@pluralistic In regards to "The dancing robot on stage at the splashy event is literally a guy in a robot-suit" I can only say WTF? Boston Dynamics had created human like (and dog like) robots, and they work.
Microsoft 365 recently introduced a massive anti-feature. You can now EITHER save document locally and do not have autosave, or save document in their cloud, and do not have local copy.
I'm not sure if it is true, or gaslighting, but apparently Word (Office 365 version) never had local autosave feature (though perhaps Word 2007 etc. did had it):
@b0rk Most of this information is available via git status... and if you are using shell or shell multiplexer usually also in shell prompt; if you are using GUI or IDE plugin, it is available in the status bar.
@pocket_recommends Terrible, terrible experience with [forced] account upgrade of #Pocket - after logging to Mozilla account, I landed on Pocket with no saves at all!!!
Only after logging out and logging in, and then trying to export my saves I have somehow finally landed on the correct account, with my saves present.
@Knusper@mac The 'head' is sometimes called 'tip of the branch' if you want to invoke the meaning of branch as a pointer to the graph of revisions, as a tip where new commits are created.
The UK government recently changed the law to ban company names containing computer code, after Michael Tandy of Hatfield registered a company called “; DROP TABLE “COMPANIES”; — LTD,” which could theoretically erase the companies house database. [Alison Thewliss MP]
commits are both snapshots, and diffs (changesets), and you can switch between these views as needed (see e.g. git-bisect or git-reset, versus git-rebase, git-cherry-pick, or git-revert)
commits can be treated as mutable (amending a commit, interactive rebase), but they are not: you are re-writing them, that is creating new modified copy (and forgetting old) - that's why you can go back with the help of reflog
@dr2chase@graydon@timbray@b0rk I think the quality of commits (most importantly: their small size, and being self-contained) matters more for easy git-bisect run than linear history.
git-bisect will be log fast even on large non-linear history.
Though having non-linear history might mean that you would have to learn about git bisect skip ;-)
@codinghorror@b0rk@vitriolix The question is how much of Git complexity is "accidental" (and could be fixed, thought backward compatibility might stand in the way), and how much is inherent in being a distributed version control system, and in allowing Git its power.
if you're an infrequent command line user -- what text editor do you use if you need to occasionally edit a file on the command line (other than vim/emacs)?
curious about what people use to edit a git commit message etc
if you picked 'other', I'd love to hear what you do in the replies!
@b0rk Depends on the machine. Usually either pico/nano, or vim. On MS Windows I used to use GitExtensions editor, on Linux I used to use GNU Emacs as GUI editor but with gnuserver - invoked from command line to open in existing Emacs window.
@b0rk There is third-party git-imerge tool that can help with rebasing a very long string of commits (and stop in the middle, and share partially rebased/merged state). Unfortunately, it looks like it is not actively developed, though I might be wrong.
today I'm thinking about the tradeoffs of using git rebase a bit. I think the goal of rebase is to have a nice linear commit history, which is something I like.
but what are the costs of using rebase? what problems has it caused for you in practice? I'm really only interested in specific bad experiences you've had here -- not opinions or general statements like “rewriting history is bad”
@b0rk It is not either merge or rebase. I often use both: rebase to keep up the feature branch up to date (or even interactive rebase to clean up history), and merge to actually join changes.
With merges, you should have git log --first-parent as nice summary of changes.
the dots thing working for diff is, I think, to be able to copy and paste line from git fetch output to git
refspec for fetch tells Git how to map references in remote repository (usually branches or branch, like refs/heads/main) into references in your repository (usually remote-tracking branches or branch, like refs/remotes/origin/main); compare how they look like when you clone the repository vs when you clone repository in the mirror mode.
@b0rk I use it to push all my local feature branches to remote with git push origin : - here : is a special kind of refspec
Before git push got --delete option it could be used to delete branch in remote repository with git push origin :branch-to-delete (push empty into branch).
If GitHub/GitLab/... is configured so that 'main' branch is protected and you cannot push there, you can use git push origin main:other-name and then create pull request/merge request.
@b0rk Also, I think if you want to share git-notes (for example to add information to existing commits, such as that it was the cause of the bug, and was fixed later), or git-replace (which can be used to connect current history with historical repo converted from some other SCM), you need to hand-craft refspec - as they both use references which are not branches.
[Julia Evans] HEAD and heads (programming.dev)
wizardzines.com/comics/head-and-heads/ - source