My first app pushed via Pythonanywhere, so I might be struggling with basic here. I successfully cloned the app from my github repository, using Personal Access Token etc. All worked well, until I lost the PAT.
Now, I would like to push changes made on Pythonanywhere repo, back to GitHub, of course, while using I was asked for the PAT.
Had to regenerate token as per 'If you’ve lost or forgotten this token, you can regenerate it, but be aware that any scripts or applications using this token will need to be updated.'
Then, I git clone https://github.com/XXXX/XXXX.git
for the same repo, username and new PAT. Which I believe was a mistake.
Now got changes to be committed, but push won't work as I get Everything up-to-date but if I run git status
I see changes ready to be committed.
What should it change? Or how to update my webapp with the new token? (.gitconfig?)
CodePudding user response:
Managed to resolve this using git reset --hard @{u}
and discard all local commits on this branch.
All changes are now made only locally and pushed, next on Pythonanywhere app only git pull
with new PAT - lessons learned.
CodePudding user response:
Now got changes to be committed, but push won't work as I get Everything up-to-date but if I run git status I see changes ready to be committed.
This has nothing to do with Python or GitHub (at least not yet, not as of this problem). It happens because git push
pushes commits. It does not push changes, nor (directly) files.
If git status
shows changes to be committed
, you have done things in your working tree—which is not actually in Git yet—and then you have run git add
to prepare whatever you did so be committed (so that it's sort of halfway into Git now). Run git commit
, write a good commit message in your chosen editor, and let the commit finish. You have now added a new commit to your Git repository!
Now you can git push
the new commit. Run git push
or git push -u origin branch
or similar to send the commit to another Git repository. What git push
does is contact some other Git software, using a URL. The URL is stored under the short name origin
(or some other short name, but origin
is the usual first one, and often the only one, so origin
is almost always the right one).
Once your Git software is talking to the other Git software, the two Git implementations look into their two—different, but presumably closely related at this point—repositories. Your repository will typically have some commit(s) that they lack. Your Git software and their Git software will use the branch name you provided here, if you provided one, to figure out which commits those are. If you omit the branch name, as in git push
with no additional arguments, your Git software uses your current branch name—the one you selected earlier when you chose to begin working—to figure out which commits those are, as if you used the current branch name in your git push
(and the name origin
, if you left that out, is also implied).
Having figured out which commits you have, but they lack, your Git software now packages up those commits and their files. Git is quite clever here, often sending only differences to files. Every commit stores a full copy of every file (in a rather magical format that eliminates data duplication), but during this communications phase, your Git has learned about the commits that their Git already has, and uses that information to be able to figure out what data they can re-use, and what new stuff they actually need. (This makes use of the same magic that eliminates duplication within a repository, but this time uses it across two separate, individual repositories.)
Having sent the commits that they lack, your Git—your software, working with your repository—now politely requests that their Git add those commits to a branch in their repository that has the same name as the branch you selected in your repository. There are forms of git push
that use different names on each side, but we have not used this form here.
If:
- they like your commit, and
- any add-ons that the hosting provider (e.g., GitHub) have added on permit this action,
then (and only then) they'll accept this git push
and update their repository to hold the new commits.
The access-granting extensions that GitHub and other hosting providers add on are where tokens (PATs and the like) come in. If you can't get into GitHub at all, or if you don't have permissions at this point, now you've reached the problem you thought you had earlier.