I have a question about git, I tried to clone a tree but without success.
git clone https://github.com/cer/event-sourcing-examples/tree/d2077e21aa677a00095f90250470ff011c132ab8/java-spring
I cloned the project
git clone https://github.com/cer/event-sourcing-examples
and I tried to switch to that tree but no effect
Would you have any suggestions ?
Best regards
Git cannot clone a tree directly. You need to clone the entire repository, and then check out a commit that uses the tree you want. For the sake of reducing confusions, though, do note that there is a difference between the terms "tree" and "commit", though:
A tree is a Git object representing a directory, and contains links to blobs (files) and other trees. A tree is not necessarily the root directory of the repository.
A commit object contains a link to the root tree of the repository, and some extra information such as commit message, dates and other headers.
You can only check out commits. Few Git commands deal directly with tree objects (git cat-file and git ls-tree being among the exceptions). However, the object ID in your GitHub URL is indeed the ID of a commit, so that's not a problem.
What you can do, then, is check out the commit you want into a new branch after you've cloned the repository:
git checkout -b test-branch d2077e21
If the problem you're trying to solve is just fetching a single commit (or tree) from a remote repository, then you're out of luck, because Git's remote protocol does not support that operation. If anything, if you can insert a branch into the remote repository at the commit you want, you can clone that branch directly, without any history:
git clone -b test-branch --depth 1 https://github.com/cer/event-sourcing-examples
If you can't do that, however, then you're still out of luck. The remote protocol only allows referencing named refs, not arbitrary commits.
Check if below things helps.Am using a GIT bash here.
Clone the repository.
git clone https://github.com/cer/event-sourcing-examples.git
Enter that directory
cd event-sourcing-examples/
Switch the branch(i am assuming by tree you mean branch)
git checkout wip-vagrant wip-vagrant is a branch name
To get the update you have to issue a pull command.
git pull
If you directly want to clone the branch then follow the instructions in above comment(Micheal).
git clone -b <branch> <remote_repo>
Example:
git clone -b my-branch git#github.com:user/myproject.git
Alternative (no public key setup needed):
git clone -b my-branch https://git#github.com/username/myproject.git
If your goal is just to get a copy of the repo at a particular commit...
While you can't use clone, you can download a zip file of the repo at a particular commit.
This method works on GitHub.
This and other approaches can be found at:
https://coderwall.com/p/xyuoza/git-cloning-specific-commits
TL;DR
Navigate to the tree view of the sha you want.
https://github.com/<repo_name>/tree/<commit_sha>
Download the zip file.
Don't clone.
Github Tree View
Open the repo and click the "commits" link
(in the bar that says "commits branches packages, etc.)
Select the commit you want. This will take you to the view showing the changes.
In the url you will see something like this:
https://github.com/Colt/webpack-demo-app/commit/eb66c0dc93141080f5b1abb335ec998a1e91d72e
- Note the sha in the url is preceeded by the word "commit".
Replace the word "commit" with the word "tree" to put yourself in the
tree view.
- Finally, click on the green "Clone or download" button
and Download the ZIP. Don't try to clone.
This will download the entire repo as it was at that commit.
First, you need to get the complete repo and get checkout the repo to commit_sha.
git clone -n <repo_name>
git checkout <commit_sha>
Related
This question already has answers here:
How do I move my local Git repository to a remote Git repository
(9 answers)
Closed 6 years ago.
I apologize if this has been asked somewhere else and I missed it. I've found many questions and answers that are close to what I'm trying to do, but none that fit exactly.
I have local files and projects in a local git repository. I created the repository a few months back as a way to safeguard and track my own work. The rest of our company uses SVN so I am the first to use git here. I set it up in my home directory on a Linux server. This repo contains many commits, branches, and tags that span my work over the past few months.
I want to move that repo to a more accessible location within our company's Linux server (not in my home directory) so others can clone and work with the entire repo (including all the tags, branches, history, etc.) as they see fit.
I've thought about copying or moving the entire file structure, but I want it to be a single file - i.e. myRepo.git.
How do I do this so that myRepo.git contains all the information I've committed such that when someone clones this repo and runs 'gitk --all', they will see all the branches, tags, etc.?
Thanks for your help.
You can git clone --bare your repo from somewhere other people can access it.
The most basic remote Git repo is nothing but a bare clone. A bare clone means it doesn't have a checkout, it's just the contents of the .git directory. Having a checkout would mean people might try to use that checkout as their own git working directory and make changes and that would get confusing with other people pushing changes to the repository.
For example, I'll make a new repository in foo/ and commit a file.
$ git init foo
Reinitialized existing Git repository in /Users/schwern/tmp/foo/.git/
$ rm -rf foo
$ git init foo
Initialized empty Git repository in /Users/schwern/tmp/foo/.git/
$ cd foo
$ touch this
$ git add this
$ git ci -m 'First commit'
[master (root-commit) 1a0bddf] First commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 this
Then I'll make a bare clone of it into bar/ (cloning doesn't have to happen over a network).
$ git clone --bare foo bar
$ ls
HEAD config description hooks info objects packed-refs refs
Instead of the checkout, it has the contents of the .git directory.
Now I can clone from that.
$ git clone bar baz
Cloning into 'baz'...
done.
$ cd baz/
$ git log
commit 1a0bddf415f48d71fa3aacc79c07c233d91ed4a9 (HEAD -> master, origin/master, origin/HEAD)
Author: Michael G. Schwern <schwern#pobox.com>
Date: Tue Feb 14 12:01:13 2017 -0800
First commit
That's cloning on a local filesystem. Git will, of course, clone over a network. Typically it uses ssh or https. git clone user#host/path is really sshing into host as user and copying what's in path.
So you can put your repo anywhere the other folks have ssh access, like a dev server, or the same host that has the SVN server.
That's the most bare bones way to share your Git repository. There are plenty of more sophisticated Git servers out there that provide web access and more protocols. Everything from the very sparse GitWeb to Gitlab, a Github clone you can host locally for free.
You can read more about this in Pro Git's chapter on Git Servers.
A fully functional git repo is not a single file, and there is no way to make it so. That said, copying your working repo isn't the best thing to do either.
If having a single file is more important that having the repo be fully functional - i.e. you don't care if your coworkers can push to it - then you can create a bundle file.
git bundle create /path/to/my/repo.bundle --all
Your coworkers can clone from this, add it as a remote, pull or fetch from it... but they can't push to it (and neither can you; to add to it you'd have to recreate it).
A shared repo to be cloned from should normally be a bare repo. This is roughly equivalent to a copy of the .git directory from your working repo. If your existing repo is at /path/to/my/repo, you can create a suitable bare repo at /path/to/shared/repo by saying
cd /path/to/shared
git clone --mirror /path/to/my/repo
Note that I used --mirror instead of --bare; this has to do with how refs are copied and will work better if you intend this to be treated as the origin henceforth.
And yet at this point /path/to/my/repo is still considered the upstream. To fix that
cd /path/to/shared/repo
git remote remove origin
cd /path/to/my/repo
git remote add origin /path/to/shared/repo
I am trying to clone my a git repository inside an existing checked out git repository and getting this failure. I've done this workflow before so I cannot figure out why it would fail now. Does anyone have any suggestions?
The git repository does exist and I can clone outside of the checked out repository in a different location
Let's say I do the following
1. cd <existing git repo clone folder>
2. git clone https://github.com/apache/cassandra
Cloning Git Repository of cassandra
Cloning into 'cassandra'...
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.
What could be causing this error?
PLEASE NOTE - I DO NOT WANT TO ADD THIS REPOSITORY AS A SUBMODULE TO MY PARENT GIT REPO. I simply want to figure out how to clone the repository in an existing working folder checked out from git.
Have a look at git submodules This was designed exactly for this. You can find information and examples here: https://git-scm.com/book/en/v2/Git-Tools-Submodules
In your case, this might work:
git submodule add https://github.com/apache/cassandra
In order to change the submodule to track a particular commit change directory to the submodule folder and switch branches as normal.
cd submodule
git checkout -b some_branch origin/some_branch
or for some particular tag
git checkout <version_tag>
You will need to commit this change to update.
Your question sort of seems to be in conflict. You can't have a git repo within another git repo without using git submodules AFAIK.
What you could do is have a dir that is not a git repo, and clone both the repos into that dir (so don't put the repos inside each other).
You could also add the repository as a remote (using git remote add name_of_remote http://your/remote/here). Then you can checkout any branch from either repo in the same repository.
I usually do not like to use submodules. for this case I would do the following:
1) in the main repo .gitignore the folder path where you want to store the repo the path-of-cassandra-repo/* (to ignore it)
2) in the terminal execute git clone https://github.com/apache/cassandra.git path-of-cassandra-repo/ where "path-of-cassandra-repo/" the name of the folder you want git to store the repo.
3) you are ready to go... Happy coding.
Let me know if this works for you...
Last week I created a Github repo and forgot to select a license for the repo. Now there are already 3 large commits.
I have asked the 3 contributors if it is ok if I delete the repo and then create it again with the same name and this time selecting the license when creating the repo, and they were fine with that.
Question
Is there a way I can get the commits into the new repo (this time the first commit is the LICENSE file) and still keep the commit meta info?
Is there a way I have get the commits into new repo (this time the first commit is the LICENSE file) and still keep the commit meta info?
Yes, by adding a remote and cherry-picking the commits on top of your first commit.
# add the old repo as a remote repository
git remote add oldrepo https://github.com/path/to/oldrepo
# get the old repo commits
git remote update
# examine the whole tree
git log --all --oneline --graph --decorate
# copy (cherry-pick) the commits from the old repo into your new local one
git cherry-pick sha-of-commit-one
git cherry-pick sha-of-commit-two
git cherry-pick sha-of-commit-three
# check your local repo is correct
git log
# send your new tree (repo state) to github
git push origin master
# remove the now-unneeded reference to oldrepo
git remote remove oldrepo
The rest of this answer is if you still want to add the LICENSE to your previous repo.
Yes. You can place your LICENSE commit as the first commit by rebasing.
Rebasing is gits way of rearranging commit order while keeping all the commit authors and commit dates intact.
When working on a shared repo, it's generally discouraged unless your entire team is git-fluent. For those that aren't, they can just clone a fresh copy of the repository.
Here's how you get your LICENSE commit as the first commit.
1. Update and rebase your local copy
Check out your project and place the LICENSE file in a commit ON TOP of your current 3 commit stack.
#create LICENSE file, edit, add content, save
git add LICENSE
git commit -m 'Initial commit'
Then do an interactive rebase on the master branch to REARRANGE the commits.
git rebase -i --root
It will open an editor. Move the bottom line (your "Initial commit" commit, the most recent commit) to the top of the file. Then save and quit the editor.
As soon as you exit the editor, git will write the commits in the order you just specified.
You now have your local copy of the repository updated. do:
git log
to verify.
2. Force push your new repo state to github
Now that your copy is updated, you have to force push it to github.
git push -f origin master
This will tell github to move the master branch to its new location.
You should only force push in rare occasions like this where everybody working with it is aware of the pending change, else it will confuse your collaborators.
3. Synchronize collaborators to github
Lastly, all the collaborators will have to synchronize to this repository.
First they must have clean repositories as the following command can be destructive if there are unsaved changes.
# make sure there are no unsaved changes
git status
# pull the latest version from github
git fetch
# move their master branch pointer to the one you published to github.
git reset --hard origin/master
That's it. Everybody should be in sync now.
I had a similar problem where I forgot to fork a repo to my github and added several commits before I realized my mistake.
I found a pretty simple solution.
First remove the remote to the original repo
git remote remove origin
Second add a remote to the new fork on my github
git remote add origin <my repo URL>
Then I pushed to origin master and all of my commits showed up on my github.
I used the following approach:
Clone the source repo to a folder like /c/SrcRepo
Clone the destination repo to a folder like /c/DstRepo and switch to the destination branch
In the root folder of the destination repo run the command:
git pull /c/SrcRepo srcBranch --allow-unrelated-histories
No necessary to create an additional remote reference
Based on #Moocowmoo's answer but trying to streamline it bit more
What this does differently is tries to avoid conflicts as much as possible, just assuming that the remote is correct.
It doesn't however handle deleted files well, so there is still a manual element.
# assuming you are already on the branch you want to be
git remote add oldrepo https://github.com/path/to/oldrepo
git fetch oldrepo
# take all or subset of changes from a branch
git cherry-pick --strategy recursive --strategy-option theirs oldestCommitHash^..latestCommitHash
# or take all changes included in a specific merge commit (easiest)
git cherry-pick --strategy recursive --strategy-option theirs mergeCommitHash^..mergeCommitHash
# handling deleted files/unhandled conflicts
# just keep repeating this section
git mergetool
# either c/m or d based on if you want to keep or delete the files
git cherry-pick --continue
Destination Git = UrlD (existing content doesn't matter)
SourceGit = UrlS
git clone UrlS
git remote add origin2 UrlD
git push -f origin2 master
Now the Destination will have the same data as Source(You can also use origin instead of origin2)
you can try this, it's easy and straightforward. This will push all commits before (and including) the hash you use as <last-commit-hash-from-old-repo> to the other repo:
git clone https://github.com/path/to/new-repo.git new-repo
cd new-repo
git remote add old https://github.com/path/to/old-repo.git
git remote update
git merge --allow-unrelated-histories <last-commit-hash-from-old-repo>
git push origin main
if anyone needs to push all commits from a repo to another as a single commit (like I needed), you can simply add --squash to the merge command like this:
git clone https://github.com/path/to/new-repo.git new-repo
cd new-repo
git remote add old https://github.com/path/to/old-repo.git
git remote update
git merge --squash --allow-unrelated-histories <last-commit-hash-from-old-repo>
git push origin main
In my case I needed to find out differences between the old and new repos. So in the new repo added the old one.
git remote add old https://gitlab.site.az/old-blog.git
Fetch all remotes
git fetch --all
Find different commits
git log --graph --oneline --pretty=format:"%h%x09%an%x09%ad%x09%s" --abbrev-commit --date=relative develop..old/develop
Get commits you selected
git cherry-pick SHA1 SHA2 SHA4
I am using the Linux kernel in an embedded project. When I started, I used git to clone from kernel.org what was then the current stable release, 3.14.2. As new 3.14 kernels were released, I was able to upgrade to them by using git rebase . For example, I upgraded to 3.14.10 by using
git checkout linux-3.14.y
git pull
git checkout myproject
git rebase v3.14.10
However, if I try to upgrade to the 3.15 series by using
git checkout linux-3.15.y
git pull
git checkout myproject
git rebase v3.15.3
or
git merge v3.15.3
I get git merge conflicts on files that I have never touched.
Is there a recommended way to upgrade from 3.14.10 to 3.15.3?
Here is what is happening. Let's say the starting commit graph looks something like this:
-------------------------------------- myproject
/
/
-----------/---------------------------------o------ linux-3.14.y
/ C v3.14.10
/ B
----/---------------------------\-------------------------- master
A \
\
--------------------o--- linux-3.15.y
v3.15.3
I don't know that it exactly looks like this, but it illustrates the issue.
When rebasing, git searches back in history for the first commit that is part of both the current branch and the "upstream" branch specified. It collects all these commits for the rebase operation.
When the "upstream" specified is the one from which the current branch was originally created, the collected commits include only my own commits on the current branch, so there are no conflicts.
When the "upstream" specified is not the one from which the current branch was originally created, which is the case for the "git rebase v3.15.3", the collected commits include ones that are not my own commits. In the example, the point of convergence is commit A, and the rebase operation would include everything from point A to myproject. The ones between point A and point C are probably inappropriate for the desired operation.
Instead, what is needed is to continue to use linux-3.14.y as the "upstream" branch for the purpose of identifying which commits to rebase, but to specify a separate commit onto which to rebase these commits. That is what the "--onto" switch is for. So the required operation to port myproject to the v3.15.y kernel is
git checkout myproject
git rebase linux-3.14.y --onto v3.15.3
First off, forgive me if this is a duplicate question. I don't know anything but the basic terminology, and it's difficult to find an answer just using laymen's terms.
I made a project, and I made a repository on Github. I've been able to work with that and upload stuff to it for some time, on Windows. The Github Windows application is nice, but I wish there was a GUI for the Linux git.
I want to be able to download the source for this project, and be able to edit it on my Linux machine, and be able to do git commit -m 'durrhurr' and have it upload it to the master repository.
Forgive me if you've already done most of this:
The first step is to set up your ssh keys if you are trying to go through ssh, if you are going through https you can skip this step. Detailed instructions are provided at https://help.github.com/articles/generating-ssh-keys
The next step is to make a local clone of the repository. Using the command line it will be git clone <url> The url you should be able to find on your github page.
After that you should be able to commit and push over the command line using git commit -am "commit message" and git push
You can use SmartGit for a GUI for git on Linux: http://www.syntevo.com/smartgit/index.html
But learning git first on the command line is generally a good idea:
Below are some basic examples assuming you are only working from the master branch:
Example for starting a local repo based on what you have from github:
git clone https://github.com/sampson-chen/sack.git
To see the status of the repo, do:
git status
Example for syncing your local repo to more recent changes on github:
git pull
Example for adding new or modified files to a "stage" for commit
git add /path/file1 /path/file2
Think of the stage as the files that you explicitly tell git to keep track of for revision control. git will see the all the files in the repo (and changes to tracked files), but it will only do work on the files that you add to a stage to be committed.
Example for committing the files in your "stage"
git commit
Example for pushing your local repo (whatever you have committed to your local repo) to github
git push
What you need to do is clone your git repository. From terminal cd to the directory you want the project in and do
git clone https://github.com/[username]/[repository].git
Remember not to use sudo as you will mess up the remote permissions.
You then need to commit any changes locally, i.e your git commit -m and then you can do.
git push
This will update the remote repository.
Lastly if you need to update your local project cd to the required directory and then:
git pull
To start working on the project in linux, clone the repo to linux machine. Add the ssh public key to github. Add your username and email to git-config.
For GUI you can use gitg.
PS : Get used to git cli, It is worth to spend time on it.