Is there a way that I can get the most recent commit on a remote repository using gitpython?
I do not want to perform operations like a pull or merge on my local branch. I also do not want to depend on the master branch on my local to get this information. All I have is a valid repo out there, and I am using repo.remotes.origin.url to get the information.
With just the repo URL, can I get the most recent commit on that repository?
Using gitpython, you can't do this without a local clone. Git is a distributed system, so it's designed for users to operate on their local repos. These answer gives some decent explanations and alternatives:
https://stackoverflow.com/a/28524371/5752730
https://stackoverflow.com/a/19391097/5752730
https://stackoverflow.com/a/16579859/5752730
Using gitpython - requires local repo
You can do a shallow clone (for speed), get latest commit SHA using git rev-parse or git ls-remote, then delete the local repo.
import git
from pathlib import Path
repo_url = 'https://github.com/path/to/your/repo.git'
local_repo_dir = Path('/path/to/your/repo')
# delete the repo if it exists, perform shallow clone, get SHA, delete repo
local_repo_dir.unlink(missing_ok=True)
repo = git.Repo.clone_from(repo_url, local_repo_dir, depth=1)
sha = repo.rev_parse('origin/master')
local_repo_dir.unlink()
print(sha)
Using python subprocess - does not require local repo
This simpler solution uses git ls-remote, which does not require a local clone. The following uses subprocess to get the SHA-1 of the given branch from the remote repo without a local clone. Note that the SHA needs to be extracted from the output response by splitting at the first tab.
import subprocess
import re
repo_url = 'https://github.com/path/to/your/repo.git'
process = subprocess.Popen(["git", "ls-remote", repo_url], stdout=subprocess.PIPE)
stdout, stderr = process.communicate()
sha = re.split(r'\t+', stdout.decode('ascii'))[0]
print(sha)
You can do it with gitpython without creating a local repository first:
remote_heads = git.cmd.Git().ls_remote(repo_url, heads=True)
Related
I am currently doing course called fullstackopen for which I created a repository on Github called fso and cloned it locally using ssh. Inside fso, I created directories for different parts(part1, part2) and created react projects inside them (using create-react-app). I pushed them to github without any problems.
For part3, the course asked to create a new repository for the backend(node js). I created this repo inside fso/part3 using git init and initialised a node app called phonebook. Now, when I tried to push it to Github, I got this:
enter image description here
So, I added my github repo using:
git remote add origin
After this when I tried to push again, I was prompted for my username and password but support for password authentication has been removed. I tried pushing using personal access tokens and got this:
enter image description here
Can I run the following in my part3/phonebook (phonbook-backend) directory?
git pull origin master git push origin master
I'm not sure if this would work, I dont want to lose my work.
Edit: i tried git pull origin main --allow-unrelated-histories and got this
pushing after this results in the same error
this is what my directory structure looks like locally. Im trying to push part3 to my github repo
Your last error is 'updates were rejected because the remote contains work'
This happens when your repository gets initialized with additional files like README or GITIGNORE. To resolve this, first you need to pull your changes from server, so you can use below command:
'git pull origin main --allow-unrelated-histories'
Then you can push your changes to server using below command:
'git push -f origin main'
I search the method to copy files to "test" host when I launch the "git push" command.
git push ------- TO REPO --> REPO_SERVER
\
\_________ TO DIR --> Host_TEST
Git Version: 2.20.1
It sounds like you are trying to (re) invent CI/CD.
If you are using GitHub or GitLab as a remote server you can use Pipelines (or Actions in GitHub).
In there you can define (almost) anything you want to happen after a push, I am assuming your Host_TEST is accessible online.
In case you are running your own git server
You can implement "push to deploy" using the post-receive hook. Hooks are scripts that are placed inside .git/hooks and executed at a precise phase of a git command. you can find several example implementations in .git/hook. See here for more information: Setting up Push-to-Deploy with git
In case you don't have access to your own git server
You can use the pre-push script on your local machine, BUT THIS IS A BAD IDEA
This hooks is executed after you execute git push but before git actually pushes anything. If your script fails (i.e non-zero return code) it will not push.
Also, if your script manages to copy but then git fails to push you will end up testing code that's not in your repo.
If all this sound way too complicated
You can create a bash function that does both operations and add it to your .bashrc.
Here is an example:
push_copy() {
if git push
then
# Copy for command here: scp ...
else
echo "Failed..."
fi
}
I have a repo having multiple branches. I am able to access all branches in my local through gitpython. However the same code i used to create gitpython's git.Repo() to create repo object but repo.branches showing only master [] though i can check manually in jenkins/workspace terminal the repo having all the branches. Can anyone help me in understanding What could be the issue?
from git import Repo
clone_my_repo("myrepo") #my function to clone the repo working fine both locally and through jenkins
module = Repo("myrepo")
print(module.branches)
[<git.Head "refs/heads/master">]
I just bought a new machine, and I'm working on a new github repo. I clone it into my machine using
git clone git#github.com:<username>/<exact-repo-name>.git
and it clones fine:
Cloning into '<exact-repo-name>'...
remote: Counting objects: ###, done.
remote: Total ### (delta 0), reused 0 (delta 0), pack-reused ###
Receiving objects: 100% (###/###), ### KiB | 0 bytes/s, done.
Resolving deltas: 100% (###/###), done.
Checking connectivity... done.
And, I add all of the remote branches locally by doing:
for remote in git branch -r; do git checkout -b $remote; done
Then, when I try to pull from any of the branches, using
git pull origin/<branch-name>
I get the ever-so-common error:
origin/<branch-name> does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
So, I go through all of the steps:
ssh -vT git#github.com
ssh-add -l
eval "$(ssh-agent -s)"
These all succeed, and I check the output of ssh-add -l and I see that it is in the list ssh keys on my github account. I go into Settings -> ssh keys, and I see the agent there.
Are there certain user permissions that are on top of those for ssh?
I agree with #Felix that this most likely is not an SSH problem, though it might be masquerading as this. Instead, I think you have a problem with your path. You can try running git clone like this:
git clone https://username#github.com/username/exact-repo-name.git
Here the username is your GitHub username. Git will prompt you for a password so you don't have to enter it as plain text. Please read this SO article for more information.
It's probably not an ssh issue, as an ssh problem would normally result in a message like
fatal: The remote end hung up unexpectedly
Most likely it's a path problem: either you have an extra slash or space in the remote path (or if there's supposed to be a space, you're missing quotation marks in your command line), or some letter is the wrong case. Double-check the rest of the URL. It could also be exactly what it says, a permissions problem -- are you sure you're connecting as the right user for this repository?
Edit: from your added details, it looks like you're just getting the syntax of the pull command mixed up. Does it work if you do this?:
git checkout <branch-name>
git pull # Edit: don't do this without reading all of 'git help pull'
? Also, does git fetch --all work? (git pull is just git fetch followed by git merge.)
Further edit: I can reproduce your error; it is a command syntax problem. Here are more examples:
"source" is a git repository in a local folder; I clone it into a folder called "dest":
$ git clone source dest
$ cd dest
Now I do the git branch command in your for loop:
$ git branch -r
origin/HEAD -> origin/master
origin/branch1
origin/branch2
origin/master
I would expect that first line to cause problems, since that would result in these commands being run in your for loop:
git checkout -b "origin/HEAD"
git checkout -b "->"
...
(Note that your example is missing backticks around `git branch -r`, so if what you posted is literally what you're running, you'll end up with branches called "git", "branch", and "-r", which would really not be what you want... if you had trouble putting backticks into inline code blocks, see https://meta.stackexchange.com/questions/55437/how-can-the-backtick-character-be-included-in-code)
Then if I try your pull command, I get the same error as you:
$ git pull origin/branch1
fatal: 'origin/branch1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
This is because git pull takes the remote repository name (origin) and the remote branch name (branch1) as two separate parameters, separated by a space. So this works:
$ git pull origin branch1
From /tmp/source
* branch branch1 -> FETCH_HEAD
Already up-to-date.
But, that's probably not quite what you want, because it sounds like you wanted to create a bunch of local branches to track the same named branches on origin (e.g. you want a local branch named "branch1" that tracks "origin/branch1"). Your local branch creation commands didn't include setting up tracking, so what you've actually got is a local branch called "origin/branch1" and a branch on remote repository "origin" also called "branch1", i.e. after running your for loop, the output of git branch -a is:
$ git branch -a
master
origin/HEAD
origin/branch1
* origin/branch2
origin/master
remotes/origin/HEAD -> origin/master
remotes/origin/branch1
remotes/origin/branch2
remotes/origin/master
...So there are two branches called "origin/branch1", and the only thing that differentiates them is that in one case, the repository is your local one and the branch's literal full name is "origin/branch1", and in the other case, the repository is the remote one (named origin) and the branch's literal full name is "branch1", which is notated as "origin/branch1" -- this will probably be very confusing to work with (and in some commands, git will complain and say, "origin/branch1 is ambiguous" and you'll have problems).
Note also that each of the new branches your for loop created is actually just a copy of master (or whatever the default/selected branch was on origin), because you didn't specify a remote branch for them to start from. That is, in your clone command, your local repository was set up with one branch selected (probably master). You then told git "make new branch from where I am now" for each line in your for loop, so each of those new branches, despite having all the different names of the branches on remote, are references to the first branch selected with your clone. This is probably not what you wanted.
I think what you actually wanted was this command, run for each remote branch:
$ git checkout --track origin/branch1
Branch branch1 set up to track remote branch branch1 from origin.
Switched to a new branch 'branch1'
Actually, if you've just done a fresh clone, a git checkout branch1 [without the -b] will have the same effect I think -- since there is no local branch called branch1, git will look for one in the repository you cloned from and set up tracking if it finds one.
...So I guess what this whole post boils down to is:
Leave out the -b in your initial checkout commands
Use a space instead of a slash in your pull command
:)
See https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches and the output of git help pull for more about remote tracking and pulling; some of it is a bit subtle (even more so than all the caveats I mentioned :) ).
I'm on a fresh install of Linux Mint.
I'm getting the following error when trying to push from any repository:
error: Malformed value for push.default: simple
error: Must be one of nothing, matching, tracking or current.
fatal: bad config file line 8 in /home/leng/.gitconfig
fatal: Could not read from remote repository.
This is very odd, because I definitely have a version that supports the simple push behavior.
The output of git --version is git version 1.8.3.2.
The contents of ~/.gitconfig:
[user]
name = My Name
email = MyEmail#website.com
[color]
ui = true
[push]
default = simple
Here's where it gets creepy.
If I change the behavior to matching (or to nothing, tracking, or current, for that matter), then attempt to push, I get the same exact error message. How is that possible? Is it caching the config somehow? I've even tried rebooting. I've even tried purging GIT completely from the system (and deleting ~/.gitconfig) then reinstalling it.
If I delete the [push] section completely from the .gitconfig file (or if I delete the file entirely), then try to push, then I get this:
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:
git config --global push.default simple
See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)
error: Malformed value for push.default: simple
error: Must be one of nothing, matching, tracking or current.
fatal: bad config file line 8 in /home/leng/.gitconfig
fatal: Could not read from remote repository.
...so it appears to be both acknowledging that I haven't chosen a pushing behavior, but then also saying that I've chosen an unsupported behavior. What on earth is going on here?
I even get the error if I delete ~/.gitconfig completely.
Can anyone help me out with this witchcraft?
Thanks!
EDIT:
Here is a .git/config file requested:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = ssh://{my remote repo}
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Okay, so I fixed it, but the method is absolute witchcraft.
I tried to isolate the problem by purging GIT, deleting the config file, reinstalling GIT, then creating a local bare repository, then cloning it, then attempting to push from there. Pretty much like this:
sudo apt-get purge git-core
rm -f ~/.gitconfig
sudo apt-get install git-core
cd /git
mkdir foo
cd foo
git init --bare
cd /var/www
git clone /git/foo
cd foo
touch blah.txt
git add -A
git config --global user.name "Name"
git config --global user.email "user#email.com"
git commit -m "Blah"
git push
...same exact error message, no change there. (Still some serious witchcraft.)
Then, I deleted one of my repositories that doesn't have a local origin (it connects to its origin via SSH) and cloned the repository anew after deleting it (with a fresh git clone ssh://... command).
I got an error from the clone command:
remote: Malformed value for push.default: simple
remote: Must be one of nothing, matching, tracking or current.
Ah ha! Now it says remote instead of error. So the remote doesn't support this behavior. (That doesn't explain why the error persists on local-only repositories with local origins, then, though.)
So I then SSH'ed into the remote server and updated the git-core there to the latest version, re-attempted to clone the repository from my local machine, and it worked.
Now, I can finally git push. Insanely, this also fixed it so I can git push from the entirely local /var/www/foo to the also entirely local /git/foo (the local origin bare repository). SSH'ing into this remote server and updating it somehow - WITCHCRAFT - fixed my local machine's error.
Why on earth the entirely local repos care about an entirely different machine's GIT version is... beyond me. How utterly, utterly insane.
I had the same error message on git push.
For me it turned out that the remote user's git was an older version (1.7.2.5),
and I had recently updated the remote ~/.gitconfig to include:
[push]
default = simple
The solution was to remove this setting from the remote's configuration.
Since it seems other people are having this issue, and I found a solution HERE, I thought I'd post the solution that worked for me.
IN SHORT:
The solution I found was at this page. Evidently the best solution is to upgrade to a newer version of Git (if possible). That was not an option for me, however. From a local machine, I typed the following command:
git config -–global push.default upstream
This got rid of the Malformed value for push.default: simple error I had been getting. I'm not entirely sure what upstream does, however.
MY CONTEXT (for comparison): I had an empty (bare) repository on a remote computer, and I had a few repositories on a couple "local" workstations. I pull from the remote repository, do some work, and then push my work to the remote repository. Pushing/pulling was accomplished via SSH. Most of the time, while working on a local machine, pushing/pulling would result in the error described above.
In short, before the fix, I had the following ~/.gitconfig file on the remote machine:
[user]
name = Foo Bar
email = FooBarPerson#email.com
[diff]
external = /Users/foobar/bin/git-diff-cmd.sh
[color]
diff = auto
status = auto
branch = auto
[push]
default = simple
After entering in the above command, my ~/.gitconfig file on the remote machine changed to:
[user]
name = Foo Bar
email = FooBarPerson#email.com
[diff]
external = /Users/foobar/bin/git-diff-cmd.sh
[color]
diff = auto
status = auto
branch = auto
[push]
default = upstream
Version information:
Remote machine (repository location): 1.9.4
My laptop: 1.8.5.2 (Apple Git-48)
Other computer I work on: 1.7.7.4
Here's another site that may be useful to some people:
http://www.lorrin.org/blog/2011/10/03/argumentless-git-pull-and-git-push/comment-page-1/