In February 2025 I followed the below procedure and it worked like a charm. My situation was that I wanted to submit a pull request to a github repo to which I was unable to push a branch. Therefore, as per the suggested procedure in these cases, I forked the original repo, created a branch, pushed it (to my forked repo) and issued the pull request from github.com. This all worked with no problem. The problem came on the next step.

After the owner of the repo accepted my pull request into his master branch, I obviously wanted to fetch their updated master branch wherein my pull request had been merged — not just to see my changes but, more importantly, to be able to create a new pull request out of the latest revision of the master branch. At that point simply doing: git fetch origin failed to achieve this as the origin for my local cloned repo (on my development machine) was obviously set to point to my own forked repo. To address this, I had to define a new remote for the upstream repo that I cloned from, and followed the below procedure:

$ git remote -v

to see the existing remotes

$ git remote add upstream https://github.com/kyp44/Topology.git

to add a new remote for the original repo I had cloned

$ git remote -v

to confirm the new remotes

$ git checkout master

to checkout the master of my forked repo into my development, locally-cloned repo

$ git fetch upstream

to fetch the upstream main branch

$ git merge upstream/master master

to merge the upstream master branch into my local master branch

$ git push origin

to push my local current (master) branch, that was just merged with the upstream master into my forked repo's remote master branch

Following the above procedure I was able to not only synchronize my cloned repo with the upstream master but was also able to quickly submit another pull request.

In January 2024 I followed this approach with good results:

$ git submodule add <url> <path>
$ git submodule absorbgitdirs <path>

source (Julia Evans blog)
PDF version

This answer is very deep; in my case I only used the first incantation:

git reset --soft HEAD@{1}

git commit -C HEAD@{1}

git stash pop
// manually resolve conflicts and save the files (NB: don't use "git add" !!)
git restore --staged .
git stash drop

These are the contents of the ~/.giconfig file on my Ubuntu 20.04 ThinkStation machine as of November 2022:

[core]
	excludesfile = /home/mperdikeas/.gitignore_global
	editor = emacs
[alias]
	lgb = log --color  --graph --pretty=format:'%C(yellow)%h%Creset -%C(bold red)%d%Creset %s %Cgreen(%cr) %C(bold blue)%Creset' --abbrev-commit
        lg  = log --color --graph --oneline --decorate
        sstatus = status -s --ignored
        ppush = "!sh -c 'git push --all && git push --tags'"
        df = difftool
        branchdate = !git for-each-ref --sort='-authordate' --format='%(refname)%09%(authordate)' refs/heads | sed -e 's-refs/heads/--'
[color]
	ui = true
        diff=always
        status=auto
        branch=auto
[diff]
	tool = vimdiff
        external = git-meld
[user]
        name = mperdikeas
        email = mperdikeas@gmail.com
[push]
	default = current
[credential]
        username = mperdikeas@gmail.com
        password=ghp_kdflk328DtBTa3KvS_obviously-mangled # I've put the PAT here, obviously mangled
	helper = store
[gc]
	auto = 0
        

source

I followed the below workflow recently:

git fetch origin pull/7/head:pr7
git checkout -t -b origin_master origin/master
git merge pr7
git push origin HEAD:master

Following the above I also did:

 git checkout -B master origin/master

Branch master set up to track remote branch master from origin.
Switched to and reset branch 'master'
Your branch is up-to-date with 'origin/master'.

This is supposedly useful when I also have commits in my local repo that I haven't pushed for a while while the collaborator has pushed his commits to github. Rebase also results in a linear history in contrast to merge. That was the theory at least; I tried that circa September 2020 and it didn't work too well …

$ git fetch -v
$ git pull --rebase origin master

NB: there should be no slash between origin and master

So failing the above I had to resort to the familiar:

git fetch -v
git merge origin/master 

In both cases you obviously still have to deal with the merge conflicts.a

To edit the checked-out branch's description:

git branch --edit-description

To view a branch's (say awesome-new-feature) description:

git config branch.awesome-new-feature.description

git branch -vv

        git log --follow -- path/to/file

source

In a recent rebase operation (where I was following the script given here), I had the following output:

$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: < some commit message >
Applying: < some commit message >
Applying: < some commit message >
Applying: < some commit message >
Using index info to reconstruct a base tree...
Mdocs/release-notes
.git/rebase-apply/patch:46: trailing whitespace.

warning: 1 line adds whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging docs/release-notes
CONFLICT (content): Merge conflict in docs/release-notes
error: Failed to merge in the changes.
Patch failed at < some commit message >
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort". 

Following the advice given in the linked source I did the following:

1. identified files in conflict (in the above example, that was docs/release-notes)
2. resolved the conflict by editing the files that are in conflict (examining and eventually removing the Git demarcation markers)
3. git add the edited files. NB: be sure to not commit at this point, no commit is necessary
4. did a git rebase --continue as that was the command Git said to do when you completed.
5. at that point, given that the rebase was successful, I saw (as expected) a fast forward merge.

git diff-tree --no-commit-id --name-only -r bd61ad98

$ git checkout 855f48bd39cf56ef3ddb94389243ebd3e5b0bb8f ../../path/to/file
$ echo 'do your tests'
$ git reset --hard
$ echo 'you are now back where you started (before the checkout)

If the "other" branch is "master" you can do a:

git merge-base HEAD master

The following can also serve to graphically show the branch point:

git log --graph --oneline --all

git stash save -u

• to get a list of files modified between any two commits (commit-id-1 and commit-id-2)

• $ git diff --name-status commit-id-1..commit-id-2

  Notes:
  • The above command reports only the name of the file and whether it was modified, deleted or added. It is meant to provide a short and compact listing of modified files so it does not report the changes as well (only the fact that a file was changed)
  • if you omit commit-id-2 it defaults to the HEAD (i.e. latest commit in your local repo)
  • if you omit both commit-id-1 and commit-id-2 it shows the uncommitted changes you've made locally to your repo.
  • to see the changes made in one particular commit there's two ways: Either provide the identifiers of that commit and its ancestor OR (better) use the ^ symbol which means "the ancestor of that commit". So the command:

    git diff --name-status fc847cb^..fc847cb

    .. shows all the changes made between the ancestor of commit git fc847cb and commit fc847cb. I.e. all the changes made in that particular commit only. E.g. if you see the following:

    $ git diff --name-status fc847cb^..fc847cb
      M       FileA.java
      M       FileB.java
      M       FileC.java

    … it means that the above three files were modified (M) in that particular commit.
• to see the changes of a particular file in single commit

Based on the example above, to see the changes made in FileB.java in the commit fc847cb (only) you can do:

git diff fc847cb^:FileA.java fc847cb:FileA.java

The above says: show me the differences of FileA.java between the direct ancestor of commit fc847cb and commit fc847cb. I.e. the differences in FileA.java made in commit fc847cb.
• to see the changes of a particular file over a range of commits

To see the changes of a particular file over a number of commits you just provide the range of the two commits (beginning commit and ending commit). E.g. to see how file FileA.java changed between commits 12347dd and fc847cb do:

git diff 12347dd:FileA.java fc847cb:FileA.java

Alternatively, the following also works:

git diff 12347dd fc847cb -- FileA.java

Instead of commit numbers you may use HEAD (for the tip of the current branch) or a branch name (in which case the tip of that branch is used)
• to see recent changes on a file against another(distant) commit

To see all changes (including unstaged ones):

 git diff --no-ext-diff 968da4d -- path/to/file

To see only up to staged changes:

git diff --no-ext-diff --staged 968da4d -- path/to/file

Notice that in the above it is an error to give HEAD after the --staged as HEAD is implicit.

To see up to the tip of the current branch:

git diff --no-ext-diff 968da4d HEAD -- path/to/file

Based on this and this, I am now resolved to using the following workflow:

1. create feature branch by branching off master
2. rebase on top of master
3. merge feature branch with master (this should be a fast forward merge)
4. remove merged branch

E.g.

$ git checkout -b cool-feature
$ git rebase master
$ git checkout master
$ git merge cool-feature
$ git branch -d cool-feature 

Say you branched off from master at some point in the past and you are now in a branch for a cool new feature. Given that in the meantime (i.e. since you branched-off) the master branch has also advanced doing (from your feature branch) the following:

git diff --name-only master

To actually only see differences since the point you branched off from master (and not to bother with subsequent master commits), you need to do (from your feature branch):

git diff --name-only master...

git stash -k -u
git checkout -b new-branch
git stash pop
git commit -m 'applied stashed changes in new branch'
git stash drop

This will stash all modifications that you did not git add:

git stash -k

Note that newly created (and non-added) files will remain in your working directory unless you also use the -u switch.

git stash -k -u

git diff

Shows the changes between the working directory and the index. This shows what has been changed, but is not staged for a commit.

git diff --cached

Shows the changes between the index and the HEAD (which is the last commit on this branch). This shows what has been added to the index and staged for a commit.

git diff HEAD

Shows all the changes between the working directory and HEAD (which includes changes in the index). This shows all the changes since the last commit, whether or not they have been staged for commit or not.

Assuming you've cloned your repository with git clone --recursive (which you always should), then do a:

git submodule update --recursive --remote

Then,

for the upstream:

you should add the submodule and commit the repository (that hosts the submodule) and push

for the downstream:

you should fetch in the repository that hosts the submodule and merge. It is not super-clear to me whether at the downstream you also need to do git submodule update --recursive --remote prior to fetching and merging the top-level repository.

1. find the path to the file
This is the first step in case you remember a few things about the file's name but have forgotten it's full path (which is necessary for the next step):

git log --diff-filter=D --summary | grep delete | grep -i file-name-fragment

2. find the commit that deleted the file
This will be the last one (hence we are using the -1 flag below):

git log -1  --stat -- full-path-to-the-file

3. resurrect the file (you can also do this in some throwaway cloned repo and then copy it manually)
To perform the resurrection use the previous commit than the one that deleted the file (hence the ^):

git checkout commit-identifier^ full-path-to-file 

The gist of the idea is to create an orphan gh-pages branch which will include only the HTML pages you wish to publish, and then push it to the origin:

1. git checkout --orphan gh-pages

2. At this point a simple git branch fails to show that you are in the new, orphan branch so do instead the following to verify you in the correct branch:

   git symbolic-ref HEAD

3. remove / add files …

4. git add . -A

5. git commit -m 'gh-pages initial'

6. git push -u origin gh-pages

7. return to master:

   git checkout master

… following the above steps it may take a couple of minutes before your site becomes visible in:
https://<your-github-id>.github.io/<repository-name>/dir/to/some/index.html

git rm the_submodule
rm -rf .git/modules/the_submodule
      

git submodule add https://github.com/fxbois/web-mode.git .emacs.d/web-mode
      

git submodule update --init --recursive

git clone --recursive git://github.com/some/repo.git
      

$ git config --global credential.helper 'cache --timeout=3600'
# Set the cache to timeout after 1 hour (setting is in seconds)
      

sudo apt-get install tig

tig [filename]

git reset --hard HEAD~1
      

git diff-tree -r df7fc29
      

git diff-tree --no-commit-id --name-only -r df7fc29
      

1. created new repository dummy on github.com
2. cloned it

cd && git clone https://github.com/mperdikeas/dummy.git

3. added a 'foo' file and pushed it

    cd dummy && echo "foo" >> foo && git add . -A
    git commit -m "foo added" && git push
        

4. created receptor SVN project in server-side SVN

cd ~/svn-playground/ && svnadmin create svn-server/dummy/

5. created a 'trunk' directory in receptor SVN project

    cd ~/svn-playground && mkdir dummy-client && cd dummy-client
    svn co file:///home/mperdikeas/svn-playground/svn-server/dummy . 
    svn mkdir trunk && svn commit -m 'created trunk directory'
        

6. configuring git svn mirror (ESAC use-case)
add the following contents to the ~/dummy/.git/config file:

[svn-remote "svn"]
    url = file:///home/mperdikeas/svn-playground/svn-server/dummy/trunk
    fetch = :refs/remotes/git-svn
        

7. Do an initial fetch of the empty subversion remote, and check it out as a new git branch (called svn)

cd ~/dummy/ && git svn fetch svn
git checkout -b svn git-svn
        

8. Merge in all your commits from master, and push them to subversion

git merge master
git svn dcommit
        

9. check that the mirroring is effected by updating on the SVN repository

10. cd ~/svn-playground/dummy-client/ && svn update
              

    (files 'foo' and 'README.md' should now be present in the dummy-client (in the trunk repository). working copy
11. To allow pushing to svn from master, rebase master to the svn branch (which can then be deleted)

12. cd ~/dummy && git checkout master
    git rebase svn && git branch -d svn
                

13. verify that you are on branch 'master' and only that branch exists

14. cd ~/dummy
    git status
    git branch
                  

15. verify the SVN read-only mirroring by removing a file, adding another and pusing the changes

echo "zoo" >> zoo && rm foo && git add -A && git commit -m "zoo added, foo removed" & git push
              

16. confirm that the changes are not yet visible to the SVN repo

cd ~/svn-playground/dummy-client/ && svn update
              

(nothing should be added)
17. push to SVN from the git repo

cd ~/dummy && git svn dcommit
              

18. view the changes in the SVN repo

cd ~/svn-playground/dummy-client/ && svn update
              

svn co http://svn.example.com/foo
cd myproj
svn mkdir trunk
svn commit -m 'Created trunk directory'
        

In our case, we have a central repository running on a local installation of Gitorious. This is a bare repository, which makes things a little tricker, as git-svn requires a working copy. To get round this, we create a clone, which we’ll use as an intermediate step in the mirroring process. If you're not mirroring a bare repository, you can omit this step.

The repositories we want to mirror are in ~git/repositories, and we’ve created a directory ~git/repositories/svn-mirror where we'll put the clones. For this example, we'll use a repository called foo/mainline.git.
Create the clone:

git clone ~git/repositories/foo/mainline.git ~git/repositories/svn-mirror/foo
cd ~git/repositories/svn-mirror/foo
            

[svn-remote "svn"]
url = http://svn.example.com/foo/trunk
fetch = :refs/remotes/git-svn
            

git svn fetch svn
git checkout -b svn git-svn
            

git merge master
git svn dcommit
            

git checkout master
git rebase svn
git branch -d svn
            

$ git log -1
# note the SHA-1 of latest commit
$ git checkout master
# reset your branch head to your previously detached commit
$ git reset --hard [commit-id]
            

git tag -l

git checkout origin/HEAD

git ls-remote --tags

• using git-format-patch:

 git format-patch 3266a7e 

(in the above example all changes between identified commit and the tip of the branch will be reported)
• using git-diff:
I suspect the tags in the following can be any tree-ish objects:

git diff 3266a7e 8deaaf2 > ~/lastchanges.patch

find . ! -type d  ! -iname nosecurity_mvn.zip -exec echo git add {} \;

git ls-tree

or..

git-ls-tree

This, and many other commands are available at /usr/lib/git-core

git tag -l -n1

git stash
git reset --hard
git clean -xf
git clean -df
git branch newBranch
git checkout newBranch
git stash pop
git add . -A -n
git commit -m "first commit on new branch"
                

git commit --amend -m "New commit message"

git log --oneline --decorate=full --graph
                

git submodule init
git submodule update
                

git rev-parse --verify HEAD
                  

- or simply -

git rev-parse HEAD
                    

git checkout -f visualization "13 - COAST Caches/ccaches_protocol_types/src/org/coast/caches/network/types/CacheGetRequest.java"

git checkout  
                    

git checkout .

                $ git clean -d -x -f
                $ git reset --hard
                    

                $ git clean -d -x -n
                    

                $ git diff master origin/master
                    

                git add . -A
                git commit -m " .. "
                    

                git config --global alias.ac '!git add . -A && git commit'
                    

                git config --global color.diff auto
                    

    git reset --hard HEAD~1
                    

    git reset --hard 
                    

    git push origin HEAD --force