git ops

1. windows path length limit

https://www.cnblogs.com/Searchor/p/17205540.html

2. git-lfs

3. config

git config --system core.longpaths true
git config --global user.name "John Doe"
git config --global user.email "jdoe@email.com"
git config --global core.autocrlf false
git config --global core.filemode false
# and for fun!
git config --global color.ui true

git config --global --add safe.directory '*'

4. clone

git clone --depth 1 -b branch_name_or_tag_name <url>

git clone --recurse-submodules https://github.com/xxxxxxx.git

5. submodule

git submodule update --recursive

git submodule update --init --recursive

git submodule update --remote --recursive

git submodule foreach --recursive git reset --hard

git submodule status --recursive

git submodule update --init --recursive --progress

# first unbinds all submodules
git submodule deinit -f .
# then checkout again
git submodule update --init --recursive
git submodule update --recursive

git submodule update --recursive looks to see which revision the parent repository has stored for each submodule, 
then checks out that revision in each submodule. 
It does NOT pull the latest commits for each submodule. 

git submodule foreach git pull origin master or 
git pull origin master --recurse-submodules 
is what you want if you intend to update each submodule to the latest from their origin repositories. 
Only then will you get pending changes in the parent repo with updated revision hashes for submodules.

list

git submodule

status

git submodule status --recursive

Answer was hidden in git submodule foreach:

git submodule foreach 'git status'

Alias for git

You can always make it simpler by assign this to alias:

git config --global alias.sb "submodule foreach \"git status\""

Now git sb give you nice information about your branches in submodules:

Entering 'vendor/submodule1'
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Entering 'vendor/submodule2'
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

https://stackoverflow.com/questions/35036774/git-submodule-status-how-to-show-current-branches-in-submodules
https://stackoverflow.com/questions/12641469/list-submodules-in-a-git-repository

6. hard reset

git fetch --origin
git reset FETCH_HEAD --hard

git reset --hard && git clean -df
git clean -df
git clean -fdx
git clean -d -f

git submodule foreach --recursive git clean -x -f -d

• git clean -f -d to get rid of untracked files and directories in your working copy.

• You can add -x to also remove ignored files.

• git clean -dfx This will delete files ignored as well.

• git clean -di will do an interactive clean which allows you to only delete the files/dirs you don't want anymore.

git fetch origin master
git checkout --force -B master origin/master
git reset --hard
git clean -fdx
git submodule update --init --recursive --force
git submodule foreach git fetch
git submodule foreach git checkout --force -B master origin/master
git submodule foreach git reset --hard
git submodule foreach git clean -fdx

7. query remote url

git config --get remote.origin.url

git remote -v

8. compare with remote

git rev-parse @
git rev-parse @{u}

# to bring your remote refs up to date
git remote update

git status -uno

If you use -v with git remote update (git remote -v update) 
you can see which branches got updated

git clean -i -fd

Remove .classpath [y/N]? N
Remove .gitignore [y/N]? N
Remove .project [y/N]? N
Remove .settings/ [y/N]? N
Remove src/com/amazon/arsdumpgenerator/inspector/ [y/N]? y
Remove src/com/amazon/arsdumpgenerator/manifest/ [y/N]? y
Remove src/com/amazon/arsdumpgenerator/s3/ [y/N]? y
Remove tst/com/amazon/arsdumpgenerator/manifest/ [y/N]? y
Remove tst/com/amazon/arsdumpgenerator/s3/ [y/N]? y

-i for interactive
-f for force
-d for directory
-x for ignored files(add if required)

Note: Add -n or --dry-run to just check what it will do.

9. network

git config --global http.proxy socks://127.0.0.1:10808
git config --global https.proxy socks://127.0.0.1:10808

git config --global http.proxy http://127.0.0.1:10808 
git config --global https.proxy https://127.0.0.1:10808

git config --list

git config --global --unset http.proxy
git config --global --unset https.proxy

gclient

win cmd, gclient, 这里用的是system

set http_proxy=127.0.0.1:10809
set https_proxy=127.0.0.1:10809
set ftp_proxy=127.0.0.1:10809
set rsync_proxy=127.0.0.1:10809
set HTTP_PROXY=127.0.0.1:10809
set HTTPS_PROXY=127.0.0.1:10809
set FTP_PROXY=127.0.0.1:10809
set RSYNC_PROXY=127.0.0.1:10809
netsh winhttp set proxy 127.0.0.1:10809

netsh winhttp reset proxy
set http_proxy=""
set https_proxy=""
set ftp_proxy=""
set rsync_proxy=""
set HTTP_PROXY=""
set HTTPS_PROXY=""
set FTP_PROXY=""
set RSYNC_PROXY=""
set all_proxy=""
set ALL_PROXY=""
git config --global --unset http.proxy
git config --global --unset https.proxy

set http.proxy=socks://127.0.0.1:10808
set https.proxy=socks://127.0.0.1:10808
set all_proxy=socks://127.0.0.1:10808

10. 列出远程分支

• git branch -r
  只列出分支名

\cpp\highway>git branch -r
  origin/HEAD -> origin/master
  origin/disable_w32_warning
  origin/master
  origin/test_360644498
  origin/v0.11.x

• git ls-remote --heads
  commit id

\cpp\highway>git ls-remote --heads
From https://github.com/google/highway.git
fbc61aca3fc99621c93ac7bb4d146e6fef669fcf        refs/heads/disable_w32_warning
cea5b104ae33417bc879547ce80aa0d98292bb09        refs/heads/master
74358f99e9ee56b958561167627716ce324d5d9d        refs/heads/test_360644498
6cf3e578ee3f3c8f61668e0cb7c0f12f4b8d876e        refs/heads/v0.11.x

• git ls-remote
  含ref信息

\cpp\highway>git ls-remote
From https://github.com/google/highway.git
cea5b104ae33417bc879547ce80aa0d98292bb09        HEAD
fbc61aca3fc99621c93ac7bb4d146e6fef669fcf        refs/heads/disable_w32_warning
cea5b104ae33417bc879547ce80aa0d98292bb09        refs/heads/master
74358f99e9ee56b958561167627716ce324d5d9d        refs/heads/test_360644498
6cf3e578ee3f3c8f61668e0cb7c0f12f4b8d876e        refs/heads/v0.11.x
...
fad06eb9cb5cb3add4d91408ccc2146483503047        refs/pull/997/head
357e21beabb1af037f20130b4195fa5d0e6bbbfb        refs/pull/998/head
18191faa5c5e617ea8e5ea92f497435bb6a6dd60        refs/tags/0.11.0
946a1b40233438a1b0363598a6deaa1628a01003        refs/tags/0.11.1
ca1a57c342cd815053abfcffa29b44eaead4f20b        refs/tags/0.12.0
d9882104caf9fb060d328d62cac9ce0a05a191db        refs/tags/0.12.1
424360251cdcfc314cfc528f53c872ecd63af0f0        refs/tags/0.12.2

xx. Compare remote branch

First use git remote update, to bring your remote refs up to date. Then you can do one of several things, such as:

• git status -uno will tell you whether the branch you are tracking is ahead, behind or has diverged.

• git show-branch *master will show you the commits in all of the branches whose names end in 'master' (eg master and origin/master).

If you use -v with git remote update : git remote -v update you can see which branches got updated, so you don't really need any further commands.

However, it looks like you want to do this in a script or program and end up with a true/false value.
If so, there are ways to check the relationship between your current HEAD commit and the head of the branch you're tracking,
although since there are four possible outcomes you can't reduce it to a yes/no answer.
However, if you're prepared to do a pull --rebase then you can treat "local is behind" and "local has diverged" as "need to pull",
and the other two ("local is ahead" and "same") as "don't need to pull".

You can get the commit id of any ref using git rev-parse <ref>, so you can do this for master and origin/master and compare them.
If they're equal, the branches are the same.

If they're unequal, you want to know which is ahead of the other.
Using git merge-base master origin/master will tell you the common ancestor of both branches,
and if they haven't diverged this will be the same as one or the other.
If you get three different ids, the branches have diverged.

To do this properly, eg in a script,
you need to be able to refer to the current branch,
and the remote branch it's tracking.

The bash prompt-setting function in /etc/bash_completion.d has some useful code for getting branch names.
However, you probably don't actually need to get the names.
Git has some neat shorthands for referring to branches and commits (as documented in git rev-parse --help).
In particular, you can use

• @ for the current branch (assuming you're not in a detached-head state) and

• @{u} for its upstream branch (eg origin/master).

So git merge-base @ @{u}

will return the (hash of the) commit at which the current branch and its upstream diverge and

git rev-parse @ and git rev-parse @{u} will give you the hashes of the two tips.

This can be summarized in the following script:

#!/bin/sh

UPSTREAM=${1:-'@{u}'}
LOCAL=$(git rev-parse @)
REMOTE=$(git rev-parse "$UPSTREAM")
BASE=$(git merge-base @ "$UPSTREAM")

if [ $LOCAL = $REMOTE ]; then
    echo "Up-to-date"
elif [ $LOCAL = $BASE ]; then
    echo "Need to pull"
elif [ $REMOTE = $BASE ]; then
    echo "Need to push"
else
    echo "Diverged"
fi

Note: older versions of git didn't allow @ on its own, so you may have to use @{0} instead.

The line UPSTREAM=${1:-'@{u}'} allows you optionally to pass an upstream branch explicitly,
in case you want to check against a different remote branch than the one configured for the current branch.
This would typically be of the form remotename/branchname. If no parameter is given, the value defaults to @{u}.

The script assumes that you've done a git fetch or git remote update first,
to bring the tracking branches up to date.

I didn't build this into the script because it's more flexible to be able to do the fetching and the comparing as separate operations,
for example if you want to compare without fetching because you already fetched recently.

https://stackoverflow.com/questions/3258243/check-if-pull-needed-in-git

invalid path

clone linux on window

git config core.protectNTFS false
git reset --hard HEAD

Turning off protectNTFS will stop Git from complaining about files that
have a base name that is reserved
but will not prevent an error if the filename is one of the reserved names.

The only workaround is to rename any offending file(s)
at the source repository or via a non-Windows client.

https://confluence.atlassian.com/bitbucketserverkb/error-invalid-path-during-git-clone-to-windows-client-1085186345.html

remote url alias

origin is an alias on your system for a particular remote repository.
It's not actually a property of that repository.
Remotes are simply an alias that store the URL of repositories.

git remote add origin https://github.com/schacon/simplegit-progit

You have a local Git repository. This repository has various settings, persisted in its configuration file.
If you add a remote, this is written to the file .git/config in your repository:

[remote "origin"]
    url = https://github.com/foo/bar
    fetch = +refs/heads/*:refs/remotes/origin/*

Now for the next push or fetch this remote is remembered.

https://git-scm.com/book/en/v2/Git-Internals-The-Refspec

See 10.5 Git Internals - The Refspec for documentation.

git push origin master
git push git@github.com:git/git.git master

get remote name

git remote -v

local remote mapping

git branch -vv

all branch

git branch -a

create delete remote branch

git push origin branchName
git push origin --delete branchName
git push --set-upstream origin branchName

gitlab CLI

https://docs.gitlab.com/ee/user/project/push_options.html

删除在本地存在，但在远端不存在的branch

git remote prune origin

git remote prune and git fetch --prune do the same thing:

delete the refs to branches that don't exist on the remote.
This is highly desirable when working in a team workflow in which remote branches are deleted after merge to main.
The second command, git fetch --prune will connect to the remote and fetch the latest remote state before pruning.
It is essentially a combination of commands:
git fetch --all && git remote prune

git clean

git clean -fd
git clean -fdx -n

• Specify -d to have it recurse into such directories as well.

• -n ,--dry-run Don’t actually remove anything, just show what would be done.

• -x Don’t use the standard ignore rules (see gitignore[5]), but still use the ignore rules given with -e options from the command line.