That is, if a loading bar pops-up that says "verifying application" or something like that when you are launching, say, your web browser, it means that the web browser has updated itself. Why? Because when the web browser updates itself, the binary file on your computer changes. When the binary changes, macOS re-verifies the binary.
- Quit (exit) the Calendar (and possibly the Mail) app.
- Remove your Google account from the "Internet Accounts" section in "System Preferences".
- Remove the "Calendars" folder from "Library" by running
sudo mv ~/Library/Calendars ~/.Trash
. - Remove the Calendar caches by running
sudo mv ~/Library/Caches/com.apple.iCal* ~/.Trash
. - Remove the Calendar preferences by running
sudo mv ~/Library/Preferences/com.apple.iCal* ~/.Trash
. - RESTART the computer. This is a must. Otherwise, it does not work.
- DO NOT ADD your Google account back from the "Internet Accounts" section in "System Preferences". Instead:
- Open the calendar app.
- Go to preferences (CMD-,).
- Click on "Accounts".
Occasionally, I press CMD-S by mistake. This causes the browser to stop responding for a few seconds while it prepares the current document to save, since CMD-S is the shortcut for it.
I almost never press CMD-S on purpose. Hence, I realized that if I can somehow disable this shortcut, this would be a good thing.
I'm not sure if it is possible to disable a keyboard shortcut for an application without downloading third-party software, but I have overridden the shortcut just by:
- Launching "System Preferences".
- Navigating to "Keyboard", "Shortcuts".
- Clicking on the plus sign to add a new shortcut.
- From the opened pop-up:
Nope, my bad. It is not silently ignored or something. In fact, the second line among the output after a commit shows the date, and it is in fact the date specified:
$ git commit -m "Add another commit" --date="2017-02-02"
[consumer_class 64a329e] Add another commit
Date: Thu Feb 2 09:42:54 2017 -0500
1 file changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 dummy.txt
$
git-filter-repo
creates entries that point to refs/replace
in the .git/packed-refs
file. Example after running git-filter-repo
:
$ cat .git/packed-refs
# pack-refs with: peeled fully-peeled sorted
bea0c96834381824ddf6cae6c79563754b0b73a2 refs/heads/some_branch
fb1be5a13f5a4acc051f4a8f9a1603446aa3e509 refs/heads/master
e3d3e5a8a7505bbf36e0c28a053cacaf3c4a9415 refs/replace/02613a4d07596a4c1f4d1b4e4c09a0b436a85404
ad87b74813174f0f04a29429e34a1fb188f83a07 refs/replace/186f2152f9359b58243bf53734ab9e587f9ee638
f5b3103f64af52a8a1012422d7fadf6d70811702 refs/replace/1aed8be9aa47c70ce9e34981322baec06a716260
Hence, if you cannot find a ref under .git/refs
directory, it is probably in the .git/packed-refs
file, which is a commit to ref mapping.
Here is a good description of what "packed refs" in Git are, taken from that manual of git-pack-refs
command:
Traditionally, tips of branches and tags (collectively known as refs) were stored one file per ref in a (sub)directory under
$GIT_DIR/refs
directory. While many branch tips tend to be updated often, most tags and some branch tips are never updated. When a repository has hundreds or thousands of tags, this one-file-per-ref format both wastes storage and hurts performance.This command is used to solve the storage and performance problem by storing the refs in a single file,
$GIT_DIR/packed-refs
. When a ref is missing from the traditional$GIT_DIR/refs
directory hierarchy, it is looked up in this file and used if found.Subsequent updates to branches always create new files under
$GIT_DIR/refs
directo
Use it as git log --graph --all --oneline
.
This shows the abbreviated commit hash and the commit subject on one line, for every ref, in a graph format. The output is colored. Also, if there is a ref associated with a commit, that ref is printed as well.
To make the commit dates show as well, use it as git log --graph --all --pretty=format:"%C(auto)%h %cd%d %s" --date=short
. Here, the pretty=format
options and their meanings are as follows:
%C(auto)
: Use automatic coloring. Without this option, the whole output is just a single color.%h
: Print the abbreviated commit hash.%cd
: Print the committer date, which is the date of the commit. This option respects (honors) the value of the--date
option.%d
: Print the ref name(s) associated with this commit. As far as I understand,d
is a reference to the--decorate
option ofgit-log
. There is no space between%cd
and%d
because%d
always has a leading space.
After fixing a merge conflict and adding the fixed file(s) to the index by running git add path-to-the-file
when running git-rebase
, DON'T RUN git commit --amend
. Just run git rebase --continue
.
If you run git commit --amend
instead of git rebase --continue
, the commit in which the conflict occurred will disappear from the commit history. Hence, DON'T run git commit --amend
after fixing a merge conflict. Run git rebase --continue
.
Let's say that when using git-rebase
, you amended a previous commit and you ran git rebase --continue
. Let's say that a merge conflict occurred. In this case, git-rebase
will pause to let you fix the merge conflict. To fix it, you need to:
- Go through each conflicted file and edit them to fix them.
- Add them to the index by running
git add path-to-the-file
.
Instead of git-rebase
, install and use git-filter-repo
as follows:
git filter-repo --commit-callback '
new_messages = {
b"0000000000000000000000000000000000000000": b"Some commit message",
b"0000000000000000000000000000000000000001": b"Another commit message",
b"0000000000000000000000000000000000000002": b"Yet another commit message",
b"0000000000000000000000000000000000000003": b"Still another commit message",
}