How can I view any local commits I've made, that haven't yet been pushed to the remote repository? Occasionally, git status will print out that my branch is X commits ahead of origin/master, but not always.
Is this a bug with my install of Git, or am I missing something?
This gives a log of all commits between origin/master and HEAD:
git log origin/master..HEAD
When HEAD is on the master branch, this gives a log of unpushed commits.
Similarly, to view the diff:
git diff origin/master..HEAD
To see all commits on all branches that have not yet been pushed:
git log --branches --not --remotes
To see the most recent commit on each branch, as well as the branch names:
git log --branches --not --remotes --simplify-by-decoration --decorate --oneline
Show all commits that you have locally but not upstream with:
git log #{u}..
#{u} or #{upstream} means the upstream branch of the current branch (see git rev-parse --help or git help revisions for details).
git cherry -v
Taken from: Git: See all unpushed commits or commits that are not in another branch.
You can do this with git log:
git log origin/master..
This assumes that origin is the name of your upstream remote and master is the name of your upstream branch. Leaving off any revision name after .. implies HEAD, which lists the new commits that haven't been pushed.
All the other answers talk about "upstream" (the branch you pull from).
But a local branch can push to a different branch than the one it pulls from.
A master might not push to the remote-tracking branch "origin/master".
The upstream branch for master might be origin/master, but it could push to the remote tracking branch origin/xxx or even anotherUpstreamRepo/yyy.
Those are set by branch.*.pushremote for the current branch along with the global remote.pushDefault value.
It is that remote-tracking branch that counts when seeking unpushed commits: the one that tracks the branch at the remote where the local branch would be pushed to.
The branch at the remote can be, again, origin/xxx or even anotherUpstreamRepo/yyy.
Git 2.5+ (Q2 2015) introduces a new shortcut for that: <branch>#{push}
See commit 29bc885, commit 3dbe9db, commit adfe5d0, commit 48c5847, commit a1ad0eb, commit e291c75, commit 979cb24, commit 1ca41a1, commit 3a429d0, commit a9f9f8c, commit 8770e6f, commit da66b27, commit f052154, commit 9e3751d, commit ee2499f [all from 21 May 2015], and commit e41bf35 [01 May 2015] by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in commit c4a8354, 05 Jun 2015)
Commit adfe5d0 explains:
sha1_name: implement #{push} shorthand
In a triangular workflow, each branch may have two distinct points of interest: the #{upstream} that you normally pull from, and the destination that you normally push to. There isn't a shorthand for the latter, but it's useful to have.
For instance, you may want to know which commits you haven't
pushed yet:
git log #{push}..
Or as a more complicated example, imagine that you normally pull changes from origin/master (which you set as your #{upstream}), and push changes to your fork (e.g., as myfork/topic).
You may push to your fork from multiple machines, requiring you to integrate the changes from the push destination, rather than upstream.
With this patch, you can just do:
git rebase #{push}
rather than typing out the full name.
Commit 29bc885 adds:
for-each-ref: accept "%(push)" format
Just as we have "%(upstream)" to report the "#{upstream}" for each ref, this patch adds "%(push)" to match "#{push}".
It supports the same tracking format modifiers as upstream (because you may want to know, for example, which branches have commits to push).
If you want to see how many commit your local branches are ahead/behind compared to the branch you are pushing to:
git for-each-ref --format="%(refname:short) %(push:track)" refs/heads
I had a commit done previously, not pushed to any branch, nor remote nor local. Just the commit. Nothing from other answers worked for me, but with:
git reflog
There I found my commit.
Handy git alias for looking for unpushed commits in current branch:
alias unpushed = !GIT_CURRENT_BRANCH=$(git name-rev --name-only HEAD) && git log origin/$GIT_CURRENT_BRANCH..$GIT_CURRENT_BRANCH --oneline
What this basically does:
git log origin/branch..branch
but also determines current branch name.
You could try....
gitk
I know it is not a pure command line option but if you have it installed and are on a GUI system it's a great way to see exactly what you are looking for plus a whole lot more.
(I'm actually kind of surprised no one mentioned it so far.)
git branch -v will show, for each local branch, whether it's "ahead" or not.
I use the following alias to get just the list of files (and the status) that have been committed but haven't been pushed (for the current branch)
git config --global alias.unpushed \
"diff origin/$(git name-rev --name-only HEAD)..HEAD --name-status"
then just do:
git unpushed
I believe the most typical way of doing this is to run something like:
git cherry --abbrev=7 -v #{upstream}
However, I personally prefer running:
git log --graph --decorate --pretty=oneline --abbrev-commit --all #{upstream}^..
which shows the commits from all branches which are not merged upstream, plus the last commit in upstream (which shows up as a root node for all the other commits). I use it so often that I have created alias noup for it.
git config --global alias.noup \
'log --graph --decorate --pretty=oneline --abbrev-commit --all #{upstream}^..'
git cherry -v
This will list out your local comment history (not yet pushed) with corresponding message
I suggest you go see the script https://github.com/badele/gitcheck, i have coded this script for check in one pass all your git repositories, and it show who has not commited and who has not pushed/pulled.
Here a sample result
It is not a bug. What you probably seeing is git status after a failed auto-merge where the changes from the remote are fetched but not yet merged.
To see the commits between local repo and remote do this:
git fetch
This is 100% safe and will not mock up your working copy. If there were changes git status wil show X commits ahead of origin/master.
You can now show log of commits that are in the remote but not in the local:
git log HEAD..origin
This worked better for me:
git log --oneline #{upstream}..
or:
git log --oneline origin/(remotebranch)..
There is tool named unpushed that scans all Git, Mercurial and Subversion repos in specified working directory and shows list of ucommited files and unpushed commits.
Installation is simple under Linux:
$ easy_install --user unpushed
or
$ sudo easy_install unpushed
to install system-wide.
Usage is simple too:
$ unpushed ~/workspace
* /home/nailgun/workspace/unpushed uncommitted (Git)
* /home/nailgun/workspace/unpushed:master unpushed (Git)
* /home/nailgun/workspace/python:new-syntax unpushed (Git)
See unpushed --help or official description for more information. It also has a cronjob script unpushed-notify for on-screen notification of uncommited and unpushed changes.
To list all unpushed commit in all branches easily you can use this command:
git log --branches #{u}..
If the number of commits that have not been pushed out is a single-digit number, which it often is, the easiest way is:
$ git checkout
git responds by telling you that you are "ahead N commits" relative your origin. So now just keep that number in mind when viewing logs. If you're "ahead by 3 commits", the top 3 commits in the history are still private.
Similar: To view unmerged branches:
git branch --all --no-merged
Those can be suspect but I recommend the answer by cxreg
one way of doing things is to list commits that are available on one branch but not another.
git log ^origin/master master
I'm really late to the party, and I'm not sure when it was implemented, but to see what a git push would do, just use the --dry-run option:
$ git push --dry-run
To ssh://bitbucket.local.lan:7999/qarepo/controller.git
540152d1..21bd921c imaging -> imaging
As said above:
git diff origin/master..HEAD
But if you are using git gui
After opening gui interface, Select "Repository"->Under that "Visualize History"
Note: Some people like to use CMD Prompt/Terminal while some like to use Git GUI (for simplicity)
If you have git submodules...
Whether you do git cherry -v or git logs #{u}.. -p, don't forget to include your submodules via
git submodule foreach --recursive 'git logs #{u}..'.
I am using the following bash script to check all of that:
unpushedCommitsCmd="git log #{u}.."; # Source: https://stackoverflow.com/a/8182309
# check if there are unpushed changes
if [ -n "$($getGitUnpushedCommits)" ]; then # Check Source: https://stackoverflow.com/a/12137501
echo "You have unpushed changes. Push them first!"
$getGitUnpushedCommits;
exit 2
fi
unpushedInSubmodules="git submodule foreach --recursive --quiet ${unpushedCommitsCmd}"; # Source: https://stackoverflow.com/a/24548122
# check if there are unpushed changes in submodules
if [ -n "$($unpushedInSubmodules)" ]; then
echo "You have unpushed changes in submodules. Push them first!"
git submodule foreach --recursive ${unpushedCommitsCmd} # not "--quiet" this time, to display details
exit 2
fi
Here's my portable solution (shell script which works on Windows too without additional install) which shows the differences from origin for all branches: git-fetch-log
An example output:
==== branch [behind 1]
> commit 652b883 (origin/branch)
| Author: BimbaLaszlo <bimbalaszlo#gmail.com>
| Date: 2016-03-10 09:11:11 +0100
|
| Commit on remote
|
o commit 2304667 (branch)
Author: BimbaLaszlo <bimbalaszlo#gmail.com>
Date: 2015-08-28 13:21:13 +0200
Commit on local
==== master [ahead 1]
< commit 280ccf8 (master)
| Author: BimbaLaszlo <bimbalaszlo#gmail.com>
| Date: 2016-03-25 21:42:55 +0100
|
| Commit on local
|
o commit 2369465 (origin/master, origin/HEAD)
Author: BimbaLaszlo <bimbalaszlo#gmail.com>
Date: 2016-03-10 09:02:52 +0100
Commit on remote
==== test [ahead 1, behind 1]
< commit 83a3161 (test)
| Author: BimbaLaszlo <bimbalaszlo#gmail.com>
| Date: 2016-03-25 22:50:00 +0100
|
| Diverged from remote
|
| > commit 4aafec7 (origin/test)
|/ Author: BimbaLaszlo <bimbalaszlo#gmail.com>
| Date: 2016-03-14 10:34:28 +0100
|
| Pushed remote
|
o commit 0fccef3
Author: BimbaLaszlo <bimbalaszlo#gmail.com>
Date: 2015-09-03 10:33:39 +0200
Last common commit
Parameters passed for log, e.g. --oneline or --patch can be used.
git show
will show all the diffs in your local commits.
git show --name-only
will show the local commit id and the name of commit.
git diff origin
Assuming your branch is set up to track the origin, then that should show you the differences.
git log origin
Will give you a summary of the commits.
I've seen lots of posts/answers on how to display all of the local commits for all local branches that have not been commited.
I have a narrow use case, and have not found an answer.
I need to determine from within a bash script, if my CURRENT branch has commits that have not been pushed upstream to the same branch. A count would be fine, but I really just need to know if a push has not yet been done. I don't care about any branches except the current branch, and in this case I've already checked to see if the branch is local (i.e. has not yet set upstream origin).
Mainly, I don't want the commits printed out. I just want to know that the number of unpushed commits is > 0.
The upstream of the current branch is #{u}. # is a synonym for HEAD.
#..#{u} selects the commits which are upstream, but not local. If there are any you are behind. We can count them with git rev-list.
# Move 4 commits behind upstream.
$ git reset --hard #{u}^^^
$ git rev-list #..#{u} --count
4
#{u}..# does the opposite. It selects commits which are local but not upstream.
# Move to upstream
$ git reset --hard #{u}
# Add a commit
$ git commit --allow-empty -m 'test'
[main 6dcf66bda1] test
$ git rev-list #{u}..# --count
1
And if both are 0 you are up to date.
Note: this will only be "up to date" as of your last fetch. Whether you want to combine this with a fetch is up to you, but one should get used to the fact that Git does not regularly talk to the network.
(I've borrowed from ElpieKay's answer).
See gitrevisions for more about #, .. and many ways to select revisions.
Suppose the branch is foo.
git fetch origin foo
git rev-list FETCH_HEAD..foo --count
The 1st command gets the latest head of the foo in the remote repository and stores its commit sha1 in FETCH_HEAD.
git rev-list returns a number. If it's 0, all commits of the foo in the local repository have been included in the foo branch in the remote repository. If it's larger than 0, there are this number of commits not included in the remote foo yet.
Being included is different from being pushed if the procedure involves a pending change like a pull request or a merge request. The commands can determine if the local branch's commits have been merged to(included in) its remote counterpart.
You're looking for git status. It will give you output like:
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
And you can grep for this with:
git status | grep -E "Your branch is ahead of '.*' by ([0-9]*) commit."
What the title says.
I want to reset each and every local branch to match my Remote repository, including deleting some branches and tags which only exists locally, without having to delete everything and cloning from scratch. All I could find are instructions on how to reset a specific branch, but not the entire repository.
Even better if it can be done from the TortoiseGit Shell extension. But I'm also fine with the command line.
You can do it by following commands:
git checkout --orphan #
git fetch <Remote> refs/*:refs/* --refmap= --prune --force
where <Remote> is remote repository you want to use. You simply fetch all remote refs (refs/*:refs/*) with --prune and --force flags to remove and force update local references.
The following line will reset all local branches that have a configured upstream branch to the state of the upstream branch
git checkout #{0} && git for-each-ref refs/heads --format '%(refname:strip=2)' | xargs -ri sh -c 'git rev-parse {}#{u} >/dev/null 2>&1 && git branch -f {} $(git rev-parse {}#{u})'
You will end up with a detached HEAD due to the first command, because you cannot reset the currently checked out branch, so checkout the branch you want to have in your working directory after doing this.
Sorry for the verbose title.
In fastlane, using the programming language Ruby, I want to have this functionality:
if remote_branch_exist
git_clone_remote_branch
else
git_clone_master
git_branch
git_push_branch_to_master
end
I have searched for a one liner git command that does that, but not succeeded. Is it possible?
I have written this code that does exactly what I want. But it must surely be an unnecessary amount of code.
def git_clone_sdk_repo(path_repo: nil)
some_branch = "some_branch"
git_url = "git#github.com:MyComp/MyRepo.git"
if check_if_remote_branch_exists(git_url: git_url, branch_name: some_branch)
puts "remote branch exists"
sh "git clone -b #{some_branch} #{git_url} #{path_repo}"
else
puts "no remote branch"
sh "git clone #{git_url} #{path_repo}"
pwd = Dir.pwd
FileUtils.cd(path_repo)
sh "git checkout -b #{some_branch}"
sh "git push --set-upstream origin #{some_branch}"
FileUtils.cd(pwd)
end
end
def check_if_remote_branch_exists(git_url: nil, branch_name: nil)
check_if_remote_branch_exists = "git ls-remote --heads #{git_url} #{branch_name} | wc -l | grep -o -q '1'"
system(check_if_remote_branch_exists)
end
(The method sh in the code block above is used to call CLI commands. I think it is part of fastlane.)
Running this command:
git clone -b <some_branch> <git_url> <path_repo>
Results in:
fatal: Remote branch <some_branch> not found in upstream origin
If there is no branch in the remote with that name. So that is why I am first checking if there is a remote branch with such a name.
What neat git command am I missing?
Let me re-express this task in Git terms, rather than as Ruby code.
You wish to:
Clone a repository from some URL. We will then save that URL under the usual "remote" name, origin.
Given a branch name such as foo, check out that particular branch (so that the current commit is the tip commit of that branch).
If the branch can be derived from a remote-tracking branch, as (e.g.) is usually true for master which usually derives from origin/master—you want Git to create this branch locally, with the corresponding remote-tracking branch set as its upstream, ready to do work on it. Hence if branch foo exists in the Git repository on origin so that origin/foo will exist in the local repository, you want to create local branch foo with origin/foo as its upstream.
If not, however—if there is no corresponding upstream name, so that at the moment, the branch is going to be a new branch—you want to create that new branch such that it points to the same commit that origin/master will point-to. In this case, you then also want to immediately (or as quickly as possible) request that the Git on origin also create this branch-name, pointing to that very same commit, and on success, set foo to have origin/foo as its upstream. Ideally, the end result of this process is that local branch foo exists and has origin/foo as its upstream.
You have observed that if foo exists on the remote, git clone -b foo <url> <directory> does the trick in one clean step (although as a side effect, the local clone will not have a master branch yet!). If foo does not exist on the remote, though, the clone fails.
Unfortunately, there is no single Git command that can do all this. Moreover, there is an atomicity issue here ("atomicity" having its usual meaning in database or parallel programming terms): the fact that foo does not exist during the cloning step does not mean that foo will not exist by the time you ask the upstream repository to create it.
The "best" answer to all of this depends on how much you care about this atomicity problem (solving it generally just moves atomicity issues to a later push step, since branch foo could be removed on the server by then, or have acquired extra commits, or been rewound and rewritten, or whatever). But in the end you must use multiple Git commands.
Method 1
The sequence that uses the least network traffic is to clone without -b. In this case, your clone will check out some branch all on its own—usually master, but the actual branch chosen will depend on what is in the HEAD entry for the Git at the URL that will be stored in the remote. Your clone will then have the remote's URL saved as usual, under the name origin (or any -o argument you supply).
Now you can simply attempt to git checkout foo. Either foo is already the current branch (because it was in HEAD on the remote), so that this is a successful no-op; or foo isn't the current branch. If foo is not the current branch, thish will create foo as a local branch with origin/foo set as its upstream if and only if origin/foo exists. This origin/foo will in turn exist if and only if a branch named foo existed on the remote at the time you did the clone (see "atomicity").
If the git checkout fails, you can assume that origin/foo does not exist. (The only other possibility is that things are going very badly wrong, e.g., you have run out of disk space or the storage device is failing, or there are bugs in Git: in both cases all bets are off.) You can at this point go down your "create foo pointing to the same commit as origin/master and use git push -u to ask to create it on origin too" path, and verify that this all works. As usual with git push, you are now racing against anyone else creating foo. Note also that there may not be an origin/master in your own repository, if there was no master on the other Git at the time you did the clone.
Method 2
You can use git ls-remote as you are doing now, which does one complete round-trip operation to the remote (currently via URL, since there is as yet no local clone, hence no remote named origin to store that URL) to determine the set of references it has. If foo does not exist in that repository, you can ask that Git to create it. You can do this a little bit differently, if you like, using a series of local Git operations in a new repository that, as yet, has nothing at all in it:
mkdir <directory>
cd <directory>
git init
git remote add origin <url>
At this point you can run git ls-remote origin, because now there is a remote named origin. However, there are no local branches at all. Now we run into the usual atomicity issues, and "what to do next" depends once again on how you wish to solve them. But if I were not using method 1 or some slight variant of it, this is what I would do next:
# assumes $branch is set to "foo" as needed, and that
# function "die" prints an error message and exits with failure
git fetch origin # bring over all commits and origin/* branches
if branchrev=$(git rev-parse -q --verify origin/$branch); then
# origin/$branch exists, so we want to act like "git clone -b $branch"
git checkout $branch ||
die "unable to check out $branch, cannot proceed"
else
# origin/$branch does not exist: ask to create it pointing to
# origin/master
rev=$(git rev-parse -q --verify origin/master) ||
die "no origin/master exists, cannot proceed"
git checkout -b $branch $rev ||
die "failed to create $branch"
git push -u origin "$branch:refs/heads/$branch" ||
die "failed to create $branch on origin"
fi
The git checkout -b creates the branch in the local repository, and sets it as the current branch. Since the initial commit ID is given by raw commit hash (due to $rev containing the result from git rev-parse), it will have no upstream. You could instead use git checkout -b $branch origin/master but this will set the upstream for the new branch to origin/master, leaving a trap for the unwary if the git push -u fails for some reason (e.g., network failure). You could use git checkout --no-track -b $branch origin/master, but given the test to make sure origin/master is a valid name, we might as well save the hash ID in $rev and use that.
This same bit of shell script—which you could rewrite in Ruby if you like—can be used after a regular old git clone, instead of using the somewhat obscure git init; git remote add ...; git fetch sequence that does everything git clone would do except for the initial git checkout of whichever branch the remote's HEAD indicates.
(In other words, in practice, I'd just run git clone—without the tricky -b part—first, then do everything in the shell script section above except the git fetch step, which is generally unnecessary right after the clone step. If the clone will take a very long time, the extra git fetch might still be useful, since that will then shrink the atomicity race, at the cost of one more round-trip to the server at origin. Nothing can completely close the race, though.)