Git Notes

Set default editor:

$ ­git­config -­global core. Editor notepad++

git init initilaizes empty repository.
.gitignore file contains folders and paths that Git will ignore. Example:

gdata/
atom/
.idea/
*.pyc

To stage and commit your changes:

Git add .
Git commit –m “your comment”

To see your config settings:

$ git config --list
core.symlinks=false
core.autocrlf=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
user.name=morpheus
user.email=
core.editor=notepad++
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly

If you modify a file after you run git add, you have to run
git add again to stage the latest version of the file:

The rules for the patterns you can put in the . gitignore file are as follows:
• Blank lines or lines starting with # are ignored.
• Standard glob patterns work.
• You can end patterns with a forward slash (/) to specify a directory.
• You can negate a pattern by starting it with an exclamation point (! ).
Glob patterns are like simplified regular expressions that shells use. An asterisk (*) matches
zero or more characters; [ abc] matches any character inside the brackets (in this case a, b, or c);
a question mark (?) matches a single character; and brackets enclosing characters separated by
a hyphen ([0- 9]) matches any character between them (in this case, 0 through 9).

Here is another example .gitignore file:

# a comment – this is ignored
*. a # no . a files
! lib. a # but do track lib. a, even though you' re ignoring . a files above
/TODO # only ignore the root TODO file, not subdir/TODO
build/ # ignore all files in the build/ directory
doc/*. txt # ignore doc/notes. txt, but not doc/server/arch. txt

If you want to see what you’ve staged that will go into your next commit, you can use git
diff –-cached
. (In Git versions 1.6.1 and later, you can also use git diff –-staged, which may
be easier to remember.) This command compares your staged changes to your last commit:

It’s important to note that git diff by itself doesn’t show all changes made since your last
commit—only changes that are still unstaged. This can be confusing, because if you’ve staged
all of your changes, git diff gives you no output.
Thus git diff = difference between latest and staged
git diff --cached = difference between staged and committed

Although it can be amazingly useful for crafting commits exactly how you want them, the staging
area is sometimes a bit more complex than you need in your workflow. If you want to skip the
staging area, Git provides a simple shortcut. Providing the -a option to the git commit command
makes Git automatically stage every file that is already tracked before doing the commit, letting
you skip the git add part:

$ git rm *~
This command removes all files that end with ~. Now consider the mv command:

$ git mv file_from file_to

This is equivalent to running something like below:

$ mv README. txt README
$ git rm README. txt
$ git add README

To see a log of changes, run:

$ git log --pretty=format:"%h - %an, %ar : %s"
ca82a6d - Scott Chacon, 11 months ago : changed the version number
085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code
a11bef0 - Scott Chacon, 11 months ago : first commit

To see the logs of past two weeks, run:

$ git log --since=2.weeks

If you want to see which commits in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this:

$ git log -- pretty=" %h: %s" - - author=gitster -- since="2008- 10- 01"
- -before="2008- 11- 01" - -no- merges - - t/

If you commit and then realize you forgot to stage the changes in a file you
wanted to add to this commit, you can do something like this:

$ git commit - m ' initial commit'
$ git add forgotten_file
$ git commit - - amend

All three of these commands end up with a single commit—the second command
replaces the results of the first.

to undo your pending changes:

$ git checkout -- FILE

to make backup on f: drive:
1. cd to f: from cmd.exe
2. run “c:Program Filesgitbinsh.exe” –login -i
3. mkdir my_repository
4. cd my_repository
5. git init –bare
6. now cd to the directory in c:
7. git push –mirror “f:my_repository” (execute this command periodically to make backups)
Counting objects: 211, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (200/200), done.
Writing objects: 100% (211/211), 124.92 KiB, done.
Total 211 (delta 108), reused 0 (delta 0)
To f:git
* [new branch] master -> master

Uploading local repository to BitBucket


1. Create empty repository on bitbucket
2. git remote add bb https://URL. this adds a remote repository named bb
3. git push bb master. this pushes the master (which is the local repo) to bb
http://git-scm.com/book/en/Git-Basics-Working-with-Remotes
You are set.
then to push updates just do:
git push bb master

To push to non-master branch use:

git push <remote> <local-branch>:<remote-branch>

e.g., git push bb master:pro

To see list of files in a commit use:

git diff-tree --no-commit-id --name-only -r 8561998a

To delete remote branch

$ git push origin --delete <name-of-remote-branch>

Adding a file and ignoring it afterwards

e.g., you want to commit launch.json but want to ignore change to it afterwards (e.g., you add a password). once you have committed a file adding it to .gitignore will not ignore it. But you can run:

git update-index --assume-unchanged .vscode/launch.json

and as the command says git will assume file has not changed (even though it has). to undo this run:

git update-index --no-assume-unchanged .vscode/launch.json

show how many commits your feature branch is ahead of main

git rev-list --left-right --count main...feature-branch

Change URL of remote repository such as the origin

git remote set-url origin git@github.com:username/repository.git

Updating your remote URL is only the first step. To get your local environment fully in sync with the new server state, you usually need to perform a “handshake” to verify the connection and update your local tracking references.

Here is how you can sync and refresh effectively:

1. Verify the Change

First, make sure the URL actually updated correctly.

git remote -v

2. Fetch the New Data

Running a fetch is the most important part. This tells your local Git to reach out to the new URL, see what branches exist there, and update its internal map of the remote.

git fetch --all --prune

  • --all: Grabs updates from all remotes.
  • --prune: This is the “refresh” part. It deletes local references to branches that no longer exist on the remote (cleaning up the “ghost” branches).

3. Re-link Your Branches (If Needed)

If you changed the remote’s name (e.g., from origin to upstream), or if you’ve moved to a completely different repository where the branch names don’t match, you might need to reset the “upstream” tracking for your current branch:

git branch --set-upstream-to=origin/main main

4. Pull the Latest

Now that the connection is refreshed, pull down the actual files:

git pull


Troubleshooting “Authentication Failed”

Since you changed the URL, your computer might still be trying to use old credentials stored in your keychain or credential manager.

  • If using HTTPS: You may be prompted for a new Personal Access Token (PAT).
  • If using SSH: Ensure your public key is added to the settings of the new host (e.g., the new GitHub or GitLab account).

Find size of untracked files

You can compute it from the index (what’s staged) or from what would be committed if you staged everything.

1) After you stage, get the exact size that will be committed

git add -A
git ls-files -s -z \
  | cut -d' ' -f2 \
  | tr '\0' '\n' \
  | git cat-file --batch-check='%(objectsize)' \
  | awk '{sum += $1} END {printf "staged blob bytes: %d (%.2f MiB)\n", sum, sum/1024/1024}'

Notes:

  • This sums the sizes of the blob objects for the staged content (i.e., what Git will store), not “working tree file sizes”.
  • This is usually what you want if your concern is “how big is this commit in Git terms?”

2) Without staging: estimate size of “everything currently untracked” (your current case)

Since your git status shows only untracked files, you can sum their on-disk sizes directly:

GNU/Linux:

du -sb .gitignore README.md dotnetipl paintings-csharp paintings-swift paintings-winforms python-scripts wordpress \
  | awk '{sum += $1} END {printf "working-tree bytes: %d (%.2f MiB)\n", sum, sum/1024/1024}'

macOS / BSD (no -b):

du -sk .gitignore README.md dotnetipl paintings-csharp paintings-swift paintings-winforms python-scripts wordpress \
  | awk '{sum += $1} END {printf "working-tree KiB: %d (%.2f MiB)\n", sum, sum/1024}'

3) If you want a one-liner that matches “what would be committed if I staged everything”, but without writing to the index

You can use Git’s pathspec from git status --porcelain and du:

git status --porcelain -z \
  | awk -v RS='\0' 'substr($0,1,2)=="??"{print substr($0,4)}' \
  | tr '\n' '\0' \
  | xargs -0 du -sb 2&gt;/dev/null \
  | awk '{sum+=$1} END {printf "untracked bytes: %d (%.2f MiB)\n", sum, sum/1024/1024}'
This entry was posted in Software and tagged . Bookmark the permalink.

Leave a comment