It is seems that Repository.checkout can only checkout a referenece.
Can we checkout any revision in the repo by SHA1-hash?
equivalent to "svn checkout -r" in subversion system
The Repository.checkout() method does only accept references or reference names, but that's by far not the only checkout method. There's Repository.checkout_tree() which lets you specify which treeish you want to check out (so you can pass a tree, a commit or a tag).
Related
Developers keep making the mistake on hotfixes to release branches in github. Here are the steps we have right now
git checkout --track origin/release_xxxx (make sure you are on the release branch)
git checkout -b yourName/yourTicketNumber (the hotfix branch)
Modify your code
Post a PR
modify the PR's base branch back to release_xxx
I am wondering if there is a slick way on the last step that once in a while gets missed to automatically use the branch it was branched from instead of main?
Perhaps I just need to create a postHotfix.sh and do the work in there but then people need github tools installed. Any other solutions?
I don't know of an automatic solution, but you can change the base branch when raising your PR in the GitHub UI:
If you're using the GitHub CLI, you can add a -B (or --base) branch as an argument: https://cli.github.com/manual/gh_pr_create
I'm coming from a perforce background, trying to understand gitHub.
In Perforce when I "checkout" something it lets other users know I am working on that file. Does checkout work the same way in Git?
It seams like you don't check out files but branches?
Thanks
checkout in Perforce would roughly equate to clone in git, but in VCS like git ( and even SVN ), the checkout doesn't signal lock to others that you are working on it. Anyone can clone a git repo and work on it without thinking about who else is working on it.
In general, checking out a branch does not mean anyone gets notified. It simply means you are switching from one branch of code to another, potentially also creating a new branch in the process depending on your arguments.
For more info about checkout, see git checkout documentation.
I am using BitBucket a GitHub repository, i would like to know how to get the Source of a particular revision?
I had committed some changes few days back, i want the entire source code for that revision, how can i get it?
Using Git, using git revisions, supposing your revision was published on master branch:
cd C:\Temp
git clone https://yourusername#bitbucket.org/repoowner/projectname
git checkout master#{2 days ago}
(not kidding, you can specify a date specification like that!)
Bitbucket is a Mercurial/Git repository, a GitHub competitor.
If you want to retrieve a specific changeset/revision, you can use either Git or Mercurial.
Using mercurial:
cd C:\Temp
hg clone https://yourusername#bitbucket.org/repoowner/projectname
hg up -r revnumber
Where revnumber is the number of the revision you want to retrieve.
What is the
HEAD
master [branch]
?
What should I choose for the "Source ref" and "Destination ref", respectively?
You see this screen in Egit Push URI documentation:
That is where you define the refspecs:
A "refspec" is used by fetch and push operations to describe the mapping between remote Ref and local Ref.
Semantically they define how local branches or tags are mapped to branches or tags in a remote repository.
In native git they are combined with a colon in the format <src>:<dst>, preceded by an optional plus sign, + to denote forced update.
In EGit they can be displayed and also edited in tabular form in the Push Ref Specification and the Fetch Ref Specification and other dialogs.
The "left-hand" side of a RefSpec is called source and the "right-hand" side is called destination.
Depending on whether the RefSpec is used for fetch or for push, the semantics of source and destination differ:
For a Push RefSpec, the source denotes a Ref in the source Repository and the destination denotes a Ref in the target Repository.
Push Refspecs
A typical example for a Push RefSpec could be
HEAD:refs/heads/master
This means that the currently checked out branch (as signified by the HEAD Reference, see Git References) will be pushed into the master branch of the remote repository.
I think you should probably check out a learning guide to understand the terminology of git. Maybe look at this site: http://gitready.com/
master is the default branch of the repo. Usually you consider this your "always working" production branch. Other work can be done in other branches and then merged into the master. "HEAD" is just the most recent changes regardless. In your case here, you would probably push to master (until you figure out branching).
In a nutshell, while you are learning git, stay on the master branch, and track the remote master branch, and push and pull from the master branch. You will soon discover a ton more amazing features of git as you go.
How can I restore files before a certain commit in GitHub?
If you want to retrieve an individual file from before the commit f4l4fe1, for example, you can do:
git checkout f4l4fe1^ -- some/file.txt
(When you add a ^ to a ref in git, it means the parent of that commit.) You should find some/file.txt back in your working tree, but note that it will also be staged as a change to commit.
If you want to just see the working tree as it was on the previous commit, you can check out the commit as if it were a branch:
git checkout f4l4fe1^
That puts you into a state known as "detached HEAD" where you're no longer on a particular branch, so making new commits won't advance any branch. To get back to master, say, you'd just do git checkout master.
As a third option, suppose you want to extract a whole directory from that commit, or a whole subdirectory, you can use git archive and pipe the output to tar, as explained in: What's the best way to extract a tree from a git repository?