I'm a beginner in Linux and Git/Github.
I tried to pull files from VSCode to github and it didn't work. It only pulled the file which I have added recently so only the one which was tracked. And the mainfile was not even modified,so it hasn't the big M behind the filename. I was watching the freecodecamp tutorial on yt about git and github for beginners and I did everything as they have shown me in the video so far.You can see it in the image below.
EDIT:
#Ashutosh Yadav
tomas#art:~/desktop/git/repo56$ git init
Initialized empty Git repository in /home/tomas/desktop/git/repo56/.git/ tomas#art:~/desktop/git/repo56$ git status
On branch master No commits yet Untracked files: (use "git add ..." to include in what will be committed) README.md nothing added to commit but untracked files present (use "git add" to track) tomas#art:~/desktop/git/repo56$ git add README.md
tomas#art:~/desktop/git/repo56$ git status
On branch master No commits yet Changes to be committed: (use "git rm --cached ..." to unstage) new file: README.md
tomas#art:~/desktop/git/repo56$ git commit -m "created README" -m "Please work test!"
[master (root-commit) b53d907] created README 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md
tomas#art:~/desktop/git/repo56$ git push origin master
fatal: 'origin' 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. CREATED NEW REPO ON GITHUB(repo56):
tomas#art:~/desktop/git/repo56$ git remote add origin git#github.com:TB20TB05TB/repo56.git tomas#art:~/desktop/git/repo56$ git remote -v origin
git#github.com:TB20TB05TB/repo56.git (fetch) origin
git#github.com:TB20TB05TB/repo56.git (push)
tomas#art:~/desktop/git/repo56$ git push origin master
Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 231 bytes | 231.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 To github.com:TB20TB05TB/repo56.git * [new branch] master -> master
As I can see in the given image, Your both files(README.md and index.html) are not saved.
Try these steps:
save both files.
click on this icon
click on + button here.
Then enter your comment in message box and press on commit.
Then click on sync/publish button at the same place.
You are done up here. Your changes are commited and pushed on gitHub.
Related
Please look at this example:
pi#rpi2:~/git/test $ mkdir remote_rep
pi#rpi2:~/git/test $ cd remote_rep/
pi#rpi2:~/git/test/remote_rep $ git init
Initialized empty Git repository in /home/pi/git/test/remote_rep/.git/
pi#rpi2:~/git/test/remote_rep $ touch readme.txt
pi#rpi2:~/git/test/remote_rep $ git add readme.txt
pi#rpi2:~/git/test/remote_rep $ git commit -m "initial commit"
[master (root-commit) 4dd0ba4] initial commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 readme.txt
pi#rpi2:~/git/test/remote_rep $ git status
On branch master
nothing to commit, working tree clean
pi#rpi2:~/git/test/remote_rep $ git log
commit 4dd0ba4797989d39dd7bb42da8de58dfac3ebad8
Author: pi <pi#abc.com>
Date: Mon Sep 21 20:13:19 2020 +0000
initial commit
pi#rpi2:~/git/test/remote_rep $ cd ..
pi#rpi2:~/git/test $ mkdir local
pi#rpi2:~/git/test $ cd local/
pi#rpi2:~/git/test/local $ git clone ~/git/test/remote_rep/
Cloning into 'remote_rep'...
done.
pi#rpi2:~/git/test/local $ ls
remote_rep
pi#rpi2:~/git/test/local $ cd remote_rep/
pi#rpi2:~/git/test/local/remote_rep $ ls
readme.txt
pi#rpi2:~/git/test/local/remote_rep $ cat readme.txt
pi#rpi2:~/git/test/local/remote_rep $ echo "abc" > readme.txt
pi#rpi2:~/git/test/local/remote_rep $ cat readme.txt
abc
pi#rpi2:~/git/test/local/remote_rep $ git commit -m "updated readme.txt"
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
modified: readme.txt
no changes added to commit
pi#rpi2:~/git/test/local/remote_rep $ git push
Everything up-to-date
pi#rpi2:~/git/test/local/remote_rep $ git remote show
origin
pi#rpi2:~/git/test/local/remote_rep $ git remote -v
origin /home/pi/git/test/remote_rep/ (fetch)
origin /home/pi/git/test/remote_rep/ (push)
pi#rpi2:~/git/test/local/remote_rep $
How come that by issuing:
pi#rpi2:~/git/test/local/remote_rep $ git push
Everything up-to-date
I got a message "Everything up-to-date", but as you can see readme.txt has been changed.
If I continue with:
pi#rpi2:~/git/test/local/remote_rep $ git add readme.txt
pi#rpi2:~/git/test/local/remote_rep $ git commit -m "updated abc"
[master 136cdba] updated abc
1 file changed, 1 insertion(+)
pi#rpi2:~/git/test/local/remote_rep $ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 241 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: is denied, because it will make the index and work tree inconsistent
remote: with what you pushed, and will require 'git reset --hard' to match
remote: the work tree to HEAD.
remote:
remote: You can set 'receive.denyCurrentBranch' configuration variable to
remote: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: its current branch; however, this is not recommended unless you
remote: arranged to update its work tree to match what you pushed in some
remote: other way.
remote:
remote: To squelch this message and still keep the default behaviour, set
remote: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To /home/pi/git/test/remote_rep/
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '/home/pi/git/test/remote_rep/'
pi#rpi2:~/git/test/local/remote_rep $
What am I missing?
git version 2.11.0
I cannot submit this question due to stackoverflow error: "It looks like your post is mostly code; please add some more details.", so I am adding here this text just to change discrepancy. Please ignore this last paragraph.
Your first git push actually succeeded, but did nothing. The reason is that your git commit -m "updated readme.txt" did nothing either, and therefore there were no commits to send. (Note that git push sends commits, not files. The commits contain files, but in this case, there was no new commit to send.)
Your second git push failed because the other Git didn't like it. That's not something you can fix from the Git that runs git push. Well, that's not entirely true: you can push a different commit, or to a different name, in an effort to please the other Git—but that's not what you should do here.
Since you actually control both Git repositories, what you should do is switch stances. Instead of acting as the client, in the client Git, you would go over to the server and work in the server Git. The error message that the server Git sent over to the client Git, that the client Git prefixed with remote: in front of each line, is exactly the message you should deliver to the person in control over the server Git. In this case, that's yourself, so now, acting as the person in control of the server, now you should pay attention to all those remote: lines. Read them now, then think about how you want the server Git to behave:
The usual solution is to have a bare repository (created with git init --bare). A bare repository has no working tree. With no working tree in it, no one can do any work in it. This means there is no problem with messing up the current work being done in the server repository: with no one working in it, there is no current work being done, and nothing to mess up. Of course, this also means you can't do any work there, but if that's what you want, that's the right way to go.
The long error message offers some alternatives, if you do want to be able to do work on the server. (It probably should also mention the updateInstead mode, which was new in Git 2.10; I'm not sure why it does not.)
The long message does not mention that if you want the server to deploy a commit, you can do that. But Git makes a fairly lousy deployment system: if you want to automatically deploy certain updates, you probably should obtain or write a deployment system, rather than just using raw Git directly.
I am using AWS SageMaker and unbeknownst to me the EC2 created a checkpoint for a .csv file that I added to .gitignore due to its size. Therefore, I accidentally added the checkpoint file to be committed.
To remove the file from staging, I performed a hard reset by executing git reset HEAD --hard.
I received the following response:
HEAD is now at c2770a8 add updates
When I executed git status, I was informed the following:
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
Consequently, I submitted git push origin master and I encountered the following error:
Counting objects: 15, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (15/15), 61.39 MiB | 5.80 MiB/s, done.
Total 15 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), done.
remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.
remote: error: Trace: cee6ca9f888bed2a49b7bbd5de9edb1a
remote: error: See http://git.io/iEPt8g for more information.
remote: error: File data/.ipynb_checkpoints/traffic_crashes-checkpoint.csv is 212.62 MB; this exceeds GitHub's file size limit of 100.00 MB
To https://github.com/Morgan-Sell/Chicago-Traffic-Risk.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://github.com/Morgan-Sell/Chicago-Traffic-Risk.git'
(1) How come the reset is not clearing my staging?
(2) How do I know what corresponds to c2770a8?
Thanks!
The problem you have is that your problem file is already committed. Adding a file to .gitignore doesn't remove it from being committed. git reset --hard HEAD (and that's how you should write it, with options before arguments) also doesn't remove files that are already committed; it resets the working tree and index to the specified commit. Since the commit already contains the problem file, you haven't changed anything in it.
What you probably want to do is git reset --soft HEAD^, assuming the latest commit is the one in which you added the problem file. That will undo your latest commit and leave all of the files staged. You can then run git reset data/.ipynb_checkpoint to remove any staged files in that directory, and the commit again.
If you added the problem file in an earlier commit, then you'll want to do a git rebase -i COMMIT^ where COMMIT is the commit that added the problem file, and then mark the problem commit as edit instead of pick, save, and quit your editor. Then, when Git stops, run git rm -r --cached data/.ipynb_checkpoints && git commit --amend --no-edit && git rebase --continue which will remove the file and finish the rebase.
I installed gitea (If someone don't know it, it's an opensource fork of gogs) on my raspberry pi. I tried it under user pi and under user git. In user pi the gitea was installed in /home/pi/gitea and in git it was installed in /home/git. In both situation the repository directory was in the install root.
I made a new repository with the webui and I tried 2 remotes with both installation.
rpilocal = pi#192.168.1.125:/home/pi/gitea/repositories/uname/repositoryname
rpilocal2 = pi#192.168.1.125:uname/repositoryname
rpigitlocal = git#192.168.1.125:/home/pi/gitea/repositories/uname/repositoryname
rpigitlocal2 = git#192.168.1.125:uname/repositoryname/repositoryname
When I tried to push on rpilocal2 and on rpigitlocal2 I got the following error message:
git push rpigitlocal2 master
git#192.168.1.125's password:
fatal: 'feralheart/leltar.git' 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.
and when I tried to push with rpilocal and rpigitlocal the push was success, BUT in the webinterface I stil got the "Make a new repository or push existing with CLI".
What's the matter?
I was working-with a test setup of gitea on a VPS♣ and encountered what may have been the same problem. After poking around with various tests, I found a workaround that is working for me. In case it could help you...
What was already working
In my case, asking gitea to create a new git repository with an initial "readme commit" was working fine. I could clone, add new commits, and push. The new commits appeared after the first one in the gitea web UI.
What wasn't working
If I asked gitea to create a repository without an initial commit†, gitea's web UI would not reflect the push of a commit history, i.e.
user#client:~/projects$ mkdir myCode
user#client:~/projects$ cd myCode
user#client:~/projects/myCode$ git init
Initialized empty Git repository in /home/user/projects/myCode/.git/
user#client:~/projects/myCode$ echo "testing 1 2 3" > file.txt
user#client:~/projects/myCode$ git add file.txt
user#client:~/projects/myCode$ git commit -m0
[master (root-commit) f9d8e7] 0
1 file changed, 1 insertion(+)
create mode 100644 file.txt
user#client:~/projects/myCode$ git remote add origin git#server:gitea_repos/owner/myCode.git
user#client:~/projects/myCode$ git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 210 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git#server:gitea_repos/owner/myCode.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.
user#client:~/projects/myCode$
git would report success and git#server:gitea_repos/owner/myCode.git would continue to function as a remote but the gitea web UI would continue to display the "empty repository" help page instead of the repository browser‡.
Work-around strategy
Because new commits were registering on repositories that started non-empty, it occurred to me that gitea might notice the change if git overwrote the stub commit history of a new project with the complete commit history of another project↯. To try this, follow:
3 Easy Steps:
In the gitea web UI, create a new repository. On the New Repository creation page, be sure to check the box next to Initialize this repository with selected files and template before clicking Create Repository.
On your workstation, add this new stub as a remote to the local git repository with the desired commit history.
user#client:~$ cd projects/myCode
user#client:~/projects/myCode$ git remote add gitea git#server:gitea_repos/owner/myCode.git
Overwrite the gitea-generated stub-commit with the intended material.
user#client:~/projects/myCode$ git push -fu gitea master
Counting objects: 97, done.
Delta compression using up to 32 threads.
Compressing objects: 100% (95/95), done.
Writing objects: 100% (97/97), 55.53 KiB | 0 bytes/s, done.
Total 97 (delta 45), reused 0 (delta 0)
To git#server:gitea_repos/owner/myCode.git
+ a1b2c3...d4e5f6 master -> master (forced update)
Branch master set up to track remote branch master from gitea.
user#client:~/projects/myCode$
Note that, for Step 3:
-f is for force: this empowers git to perform the (otherwise prohibited) "commit tree overwrite"
-u is for set-upstream - this connects local branch master through the remote-tracking branch gitea/master to the master branch managed by gitea
Follow through
This strategy is something of a hack and I suspect it leaves a few things undone. E.g. you might want to push branches and tags up to gitea. (My tests haven't taken me this far.) Consider --all for branches and --tags for tags:
user#client:~/projects/myCode$ git push gitea --all
user#client:~/projects/myCode$ git push gitea --tags
While YMMV, I wish you luck!
Footnotes:
♣ - I am working with gitea-1.4.2-linux-amd64 on Ubuntu 16.04.2 LTS hosted at virmach.com.
† - git uses the term "empty repository" when referring to a repository w/o commits but, in the internal API used by gitea to access git features (and, occasionally, by gitea community members), the term "bare repository"☥ is used.
☥ - git uses the term "bare repository" when referring to a repository not embedded (as the directory ./.git) in the root directory of a "working tree". Bare repositories are frequently used as a canonical copy for collaboration and are stored on (and accessible from) a server. E.g. the 'github' service. Sometimes these directories are named with the schema project_name.git
‡ - I tried a number of setup variations, asked around on irc channel #gitea, and poked around in the code. All I can conclude is that some difference in the git→hooks→gitea chain (varying between empty and non-empty repositories) is responsible for this problem on my VPS.
↯ - Before this, I thought of replaying the history of the desired project over the new stub but this rebase operation is a desperate hack: all the commits get new sha checksums and, essentially, all developers would have to clone-in again as if working on a new repository.
I have a problem with git, here my process
I create a file git on the dev serv
git init --bare .git
I clone this repository .git on my local pc.
git clone ssh://root#ipservdev.com/var/www/siteweb/.git
i add all my files
cd /var/www/siteweb
git add *
git commit -m "First Commit"
git push -u ssh://root#ipservdev.com/var/www/siteweb/.git master
But, i back on my dev server, none file of my site are uploaded (ex : index.php, config.php or others) . Why ?
Buy, I have no error.
Counting objects: 3, done.
Writing objects: 100% (3/3), 234 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://root#ipservdev/var/www/siteweb/.git
* [new branch] master -> master
Branch master set up to track remote branch master from ssh://root#ipservdev/var/www/siteweb/.git.
Your repository is a 'bare repository', it didn't have a working directory with your pulled files.
Edit: I answer here, just for make it more clear and complete.
As far as I know, you have here three options:
From the most old repo, do a git pull targeting the most new repo, or make a merge
Do the push to another branch, the master branch is 'special'
Use a bare repo (like you do initially) to push it your commits, but you can't see the files because it didn't have a working directory
Also I recommend you to read de pro-git book it's really useful and you will see a lot of common use cases.
Hope i help you!
I have a theme I use for our merchant store. I use git to maintain a repo (local repo 1) of this theme that i clone into a dev folder (local repo 2) and then work on there, when I'm done I want to update (push?) to the original local repo 1. From there I can render zip files or whatever I need for the merchant store.
So i made repo1 by git init and adding the files and committing it. worked fine. Then I cloned the repo to my dev folder and setup my web services there. Worked great. I edited my theme and made commits appropriately. Now that I am ready to put these changes on the live server I want to push to my origin which should be repo 1. However after making commits when I try to push from repo2 by
git checkout master
and then
git merge classes-migration
and then
git push
it says "everything up to date" I've tried specifying specifically the same branch to push, honestly I've tried all kinds of things reading through the different answers here.
git branch [for repo1]
classes-migration
import-classes-migration
initial-commit
* master
git status [for repo1]
On branch master
nothing to commit, working directory clean
git branch [for repo2]
classes-migration
* master
git status [for repo2]
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
git remote show origin [for repo2]
* remote origin
Fetch URL: /home/user/projects/merchant/repos/theme
Push URL: /home/user/projects/merchant/repos/theme
HEAD branch: master
Remote branches:
classes-migration tracked
import-classes-migration new (next fetch will store in remotes/origin)
initial-commit tracked
master tracked
Local branches configured for 'git pull':
classes-migration merges with remote classes-migration
master merges with remote master
Local refs configured for 'git push':
classes-migration pushes to classes-migration (up to date)
master pushes to master (up to date)
So.. yeah.
The push command is used to put in the server what you already has committed.
If you have a git repository configured, clone it in your dev machine, then work in this project. After that you need to commit your changes.
first check the status after the changes:
git status
If you get this message
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: filename.txt
no changes added to commit (use "git add" and/or "git commit -a")
It means you`ve changed the file filename.txt, if you've changed more then one file, every file will be listed here.
The next step is commit the file.
git commit filename.txt -m "commit comments"
Just after that, you push to the server:
git push
After this command, when you clone in another machine or update the repository the user will see the modifications.