GIT - Index of commands

1. setup of "repoOrigin" :
   export TMPDIR='/run/shm/'; repoOriginDir=$(mktemp -d); cd "$repoOriginDir"; git init; echo 'hello world' > myFile; git add myFile; git commit -m 'initial version'; git log; cat myFile
2. setup of "repo2", as a clone of "repoOrigin" :
   repo2Dir=$(mktemp -d); cd "$repo2Dir"; git clone "$repoOriginDir" .; git log; cat myFile
3. create new branch on "repoOrigin" :
   branchName='myBranch'; cd "$repoOriginDir"; git checkout -b "$branchName"; echo "hello to all my friends from the '$branchName' branch" >> myFile; git add myFile; git commit -m 'for my friends'; cat myFile; git log
4. making sure there is different stuff on branches of "repoOrigin" :
   git checkout master; cat myFile; git log
5. let's get the "$branchName" branch on "repo2" :
   cd "$repo2Dir"; git fetch origin "$branchName":"$branchName"; git branch; git log; cat myFile
6. so far, nothing in git branch / git log or in files. Lets view the contents of "$branchName" on "repo2" :
   git checkout "$branchName"; git branch; git log; cat myFile
7. make changes on "$branchName" from "repo2" :
   echo "I made this change into '$branchName' from 'repo2'" >> myFile; git add myFile; git commit -m 'changed from repo2'; git log
8. to get this change in "repoOrigin", we have to declare a "remote" first :
   remoteName='repo2'; cd "$repoOriginDir"; git remote add "$remoteName" "$repo2Dir"; git remote -v
9. now get stuff :
   • git fetch "$remoteName"; git checkout "$branchName"; git branch; git log; cat myFile
     no error, but doesn't receive the "changed from repo2" commit
   • git fetch "$remoteName" "$branchName"; git checkout "$branchName"; git branch; git log; cat myFile
     no error, but doesn't receive the "changed from repo2" commit
   • git fetch "$remoteName" "$branchName":"$branchName"; git checkout "$branchName"; git branch; git log; cat myFile
     gets the "changed from repo2" commit
10. clean before leaving :
    cd "$TMPDIR" && for workDir in "$repoOriginDir" "$repo2Dir"; do [ -d "$workDir" ] && rm -rf "$workDir"; done

git show otherBranch:myFile

This is equivalent to git checkout otherBranch && cat myFile, but better

git push -u remote localBranchName

• git diff olderCommitId newerCommitId path/to/file
• git diff olderCommitId..newerCommitId --color-words myFile

• on the current commit :
  • git tag -a tagName (opens editor for tag message)
  • git tag -a tagName -m 'tagMessage'
• on an other commit :
  • git tag -a tagName commitId -m 'tagMessage'

• an explicit date :
  git log --after='2019-03-29'
  When no time is specified, it defaults to 00:00:00 : the behavior (include / exclude commits) depends on whether you're asking for commits before or after this point in time.
• an explicit timestamp :
  git log --before='2019-03-29T13:40:00+01:00'
  • based on the ISO 8601 format
  • read this too
• relative dates :
  • git log --after='3 days ago'
    (looks like ago is optional)
  • git log --after='2 weeks 3 days 2 hours 30 minutes 59 seconds'

There is no such thing like "source" or "destination" branches when merging, but this reminds me of the new "arrow" that will be added to the commit tree :

before :

	      A---B---C feature
	     /
	D---E---F---G master

after git merge feature master :

	      A---B---C feature
	     /         ↘
	D---E---F---G---H master

• The order branch_A branch_B or branch_B branch_A matters in that it will replay commits of (the 1st one) onto (the 2nd one) since they diverged. This means the whole set of commits "lands" on (the 2nd one). This is important when it comes to deleting merged branches.
• destinationBranch can be omitted if it's the current branch :
  git merge sourceBranch
• git merge parameters are commit IDs (which is somewhat equivalent to branch names, since all of this relates to objects IDs anyway)
• Merging generates a new commit that has 2 parents (Except if the "destination" branch remained untouched since the creation of the branch. In such a case, a fast-forward merge will be performed automatically (source)).

1. delete the remote branch
   • git push remote :branch
   • or : git push -d remote branch
     -d is an alias of --delete
2. delete the local branch :
   git branch -d fullyMergedBranch

Alternate workflow with GitLab & al. :

• record the current state of the working directory and the index, but want to go back to a clean working directory. git stash saves your local modifications away and reverts the working directory to match the HEAD commit.
• "move" uncommitted changes to another branch :
  1. git stash
  2. git checkout myOtherBranch
  3. git stash pop

• git stash save : create a new stash. Can be shortened to : git stash, which will create an "anonymous" stash with default options
• git stash list : list existing stashes
• git stash show : show the changes recorded in the stash as a diff between the stashed state and its original parent (see example below)
• git stash pop : remove a single stashed state from the stash list and apply it on top of the current working tree state (i.e. do the inverse operation of git stash save)
• git stash apply : like git stash pop, but do not remove the state from the stash list
• git stash clear : remove all the stashed states
• git stash drop : remove a single stashed state from the stash list. Defaults to the latest one if no stash ID is given (see example below)

1. List stashed content :
   git stash list

   stash@{0}: WIP on master: ce9100b a great commit message
   stash@{1}: WIP on master: 0765a47 another GREAT commit message
   stash@{2}: WIP on master: cfc2b09 this one is not as great as the others, but still good, though 

   stash@{0} is the latest stash.
2. List files affected by a single stash :
   git stash show 0

    someFile | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

3. View the actual changes made in the stashed content :
   git stash show -p 0
4. Discard stashed content :
   • the latest stash :
     1. git stash drop

        Dropped refs/stash@{0} (20f3a793f379e266cde2131e740591ae186fc188)		don't know (yet!) what this ID (commit ID?) refers to 

     2. git stash list

        stash@{0}: WIP on master: 0765a47 another GREAT commit message			decremented stash IDs
        stash@{1}: WIP on master: cfc2b09 this one is not as great as the others, but still good, though 

   • another stash :
     1. git stash drop 1

        Dropped refs/stash@{1} (6615a1409aa713cc8ec9a8c6a8277b19e06cacc7)

     2. git stash list

        stash@{0}: WIP on master: 0765a47 another GREAT commit message			decremented stash IDs

        There's only 1 stash left because I actually run both drop commands successively (latest stash + another stash) while writing this article.

Enumerating objects: 30475, done.
Counting objects: 100% (30475/30475), done.
Delta compression using up to 2 threads
Compressing objects: 100% (8783/8783), done.
Writing objects: 100% (30475/30475), done.
Total 30475 (delta 21751), reused 30115 (delta 21522)

Total 30475

total number of objects in the repository

(delta 21751) (1^st delta)

number of those total objects which are binary delta objects i.e. how many objects Git has decided have a strong similarity with other objects and can be stored as a binary delta.

reused 30115

how many objects from a compressed source (i.e. a packfile, see .git/objects/pack/*pack) are being used without having been recompressed to include more recent changes. This would occur when you have multiple packfiles but where a more recent SHA object refers to an item in an old packfile as its base, then applies deltas to it to make it modern. This lets Git make use of previously compressed older revisions of data without having to recompress it to include more recent additions. Note that Git may append to an existing pack file without rewriting the entire pack file

delta 21522 (2^nd delta)

?