ugultopu

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

ugultopu

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

ugultopu

Update

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
$ 

ugultopu

For example, let's say you have a commit graph like the following. That is, the following is the output of git log --graph --all --pretty=format:"%C(auto)%h %ad%d %s" --date=short:

* 87b5f13 2017-02-26 (HEAD -> master) Put received locations into a queue
* 625118a 2017-02-21 Disable output buffering on non-interactive run
* 3be0b85 2017-02-21 Send averaged latitude and longitude to client
* 1b8bd08 2017-02-20 Require verbose mention of dev or prod
* a1d9ba0 2017-02-20 Ignore nohup.out
* 2797ac1 2017-02-20 Customize script/runserver for dev and prod
* 0a8110f 2017-02-20 Check for the accuracy of received location

ugultopu

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:

ugultopu

• 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".

ugultopu

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.

ugultopu

As far as I can tell, you can't do it conveniently. That is, git-rebase does not give you an option to preserve the committer date. Unless you give the --ignore-date (or its alias, --reset-author-date) option, it will always preserve the author date. However, there is no way to make git-rebase preserve the committer date, unless some manual script is crafted.

The best you can do is to make the committer date equal to the author date. Recently (in 2020 Q4), git-rebase --interactive has gained the ability to use the --committer-date-is-author-date flag with the interactive rebase. Before that, there was no way of influencing the committer date at all with the interactive rebase. Note that this flag does not preserve the committer date. It merely makes the committer date equal to the author date.

You might be thinking "well, isn't that effectively preserving the committer date, since normally the committer date is always equal to the author date?". Normally, you would be correct. However, there

ugultopu

Opening a .docx file on a text editor won't mean anything, because a .docx file is a compressed file. To access the content in a .docx file, you can decompress it by running:

unzip path/to/file.docx

The better thing would be to create a directory and then run the command, in order for all files to be extracted to the same place:

mkdir document-contents
cd document-contents
unzip ../path/to/file.docx

ugultopu

strings.reduce(
  (max, string) => string.length > max ? string.length : max,
  0
);
// Or, more verbose version:
strings.reduce(
  (max, string) => {
    if (string.length > max) return string.length;
    else return max;
  },