After cloning a remote git repository and issuing git show --show-signature, it says the signature is good. Then I changed some files and tested the same command, and it still says the signature is good.
What exactly does the above command check? What is the correct way to verify the cloned git is what is meant by the developer?
git show --show-signature does exactly what it says in its manpage:
--show-signature
Check the validity of a signed commit object by passing the signature to gpg --verify and show the output.
You must have imported a repo author's public key before so that GPG
can know where to look for it. You need to read up on a tutorial to
learn how GPG works to fully understand how it works.
Now for the second part of your question, git show without an
explicit commit SHA-1 or object name in general works on current
HEAD. If you just modified some files in your working copy but
didn't commit the changes then HEAD and all other commits in your
repository will stay the same, therefore git show --show-signature
will show you exactly the same as it would after a fresh cloning of
the repository. If you'd decide to commit your changes you will move
your HEAD one commit up but won't modify previous HEAD so git show --show-signature HEAD^ will still show everything is ok.
Commits don't change. git status will report on the status of your worktree; git show is for showing you repository content.
Related
I have a CI pipeline that is likely doing something semi-perverted. Let's not debate that part.
As part of the CI, I will generate an artifact (README.md) which I would like to commit and push back to the same repository. Simply using git push origin ... doesn't work due to authentication error.
Am I constrained to using something like a secret variable and a token, and adding another remote so that it can push?
There are ways to add a ssh token to your build runtime which is able to commit or even do a push to origin.
I think even recently GitLab added a new functionality that for each build a unique token is generated which can be used for same sake.
However in general I dont think you can commit anything on the same git base that build is running on, as the check out is in a detached head mode. This means you will not be able to add to history, specially in a remote.
Next problem to consider is what this means if you were able to commit back for the build system, which can potentially trigger another build and a cycle will be triggered.
So probably either use the artifact system for it or do add the ssh token and clone/checkout/commit/push in a separate directory during the build. Anyway this doc explains how to add the token: https://docs.gitlab.com/ee/ci/ssh_keys/README.html
Gitlab seems to change .git folder after fetching project for CI job. I'm not sure it changes only remote section. So I found only solution is to add gitlab-runner user with sshkeys to gitlab. And in my job make git clone in separate folder, make changes, then commit and push it.
In my company, we have moved from svn to git. We did not use any third party tools for this. We ran git svn clone --stdlayout --no-metadata --authors-file=authors.txt temp_name. This seemed suffucient to get what we wanted. We then pushed the repos to bitbucket. However what we noticed after pushing is, in one of the repos, a branch was missing in bitbucket. So, I did a checkout of the branch, then I got the message
"You are in detached HEAD state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout." Then I googled for resolving the detached head problem but none of the posts talks about the detached head after git svn clone. The main thing I want to achieve is I just want the detached branch pushed to remote master immediately after git svn clone. I do not know what I'm missing
Don't worry much about the detached HEAD message itself. As long as you get the needed revisions in your working copy, simply push it where you want them to be:
git push <your_bit_bucket_remote> <revision>:refs/heads/<branch_name_at_bitbucket>
where <revision> can be something like HEAD, svn/branch_name or an explicit SHA1.
I have an already existing git-svn repo with an ignore paths in my .config file that looks like this:
ignore-paths = ^(?!(Path1/Proj1|Path1/Proj2|Path2/Proj3))
This works well.
Someone added a new project in svn that I now need in my git repo.
If I change ignore-paths to what's below and issue a fetch or a rebase, I never see Path2/Proj4
ignore-paths = ^(?!(Path1/Proj1|Path1/Proj2|Path2/Proj3|Path2/Proj4))
In the past, I've always given up and blasted away my git repo and recreated it. Is there a better way?
After editing the ignore-paths you need to
git svn reset -r <n> -p # where <n> is the SVN revision where the new path was added.
git svn fetch
git rebase # or reset
Reference git-svn(1):
reset
Undoes the effects of fetch back to the specified revision.
This allows you to re-fetch an SVN revision. Normally the
contents of an SVN revision should never change and reset
should not be necessary. However, if SVN permissions change,
or if you alter your --ignore-paths option, a fetch may fail
with "not found in commit" (file not previously visible) or
"checksum mismatch" (missed a modification). If the problem
file cannot be ignored forever (with --ignore-paths) the only
way to repair the repo is to use reset.
Only the rev_map and refs/remotes/git-svn are changed (see
$GIT_DIR/svn/*\*/.rev_map.* in the FILES section below for details).
Follow reset with a fetch and then git reset or git rebase to
move local branches onto the new tree.
In Xcode we pulled someone else's push and merged with local copy. However now the pulled copy has corrupted storyboard. The worst thing is we accidentally pushed those corrupted file to remote repo. Now is there any way I can solve this issue?
we are using SourceTree as our interface to Git.
One of our member has the last working copy as we haven't pulled any corrupted data from server to his copy.
Any potential solution for this situation? Thanks
Sorry but I'm not enough of a Git expert be be able to give you the exact commands, but there are git commands you can enter to revert a file to a specific revision/commit. If you hunt around the web you should be able to find them and revert the file.
You may have to use command line Git.
This may help Reset or revert a specific file to a specific revision using Git?
and this Rollback file to much earlier version using Git
A pull and merge is commited to the history like any other change so you just need to undo that commit. The git command to delete the last commit and restore your working tree to the previous commit is:
git reset --hard HEAD~1
(from Delete commits from a branch in Git)
This change could then be pushed back up to your server.
I'm using git-svn. I've moved file 'A' to 'B' and I'm up to date with the svn HEAD (using git svn rebase). I can commit all other changes without problems. Now I've decided that I want to move 'B' back to 'A' and commit that change.
When I do the move and commit to my local master it works fine, but I get the following when doing a git svn dcommit:
Transaction is out of date: Out of date: 'A' in transaction '3652-1' at /opt/local/libexec/git-core/git-svn line 570
So I tried to copy and delete in a separate commit which resulted in:
Item already exists in filesystem: File already exists: filesystem '/usr/svn/db', transaction '3652-1', path 'A' at /opt/local/libexec/git-core/git-svn line 4735
I've recovered from this situation with plain svn by using the workarounds like the one described in the documentation, but I don't know how to recover with git-svn. What is going on and how do I fix it?
Removing .git/svn did not work for me. Instead, here's how I resolved:
Deleted the offending directories from the repository (But I'm not sure that this is necessary. In hindsight I think I could have skipped this step)
git svn rebase
During the rebase, there were some conflicts. For each conflict, I resolved the conflicts in text editor, then used git add <file-in-conflict> and then git rebase --continue
After rebase completed successfully, git svn dcommit ran successfully!
I can't claim to understand what's really going on under the hood in git-svn in this case (although the underlying SVN issue makes perfect sense). My usual strategy when git-svn gets confused somehow is to blow away the .git/svn metadata directory (as in this post). This almost always saves me from odd synchronization issues between the git and SVN repositories.
It happened with me when I interrupted the dcommit process.
Follow these steps to recover from error:
git svn rebase
You will get conflicts in files. Resolve the conflicts & then git add filename (in which conflict occurred) for each file.
Now do git svn dcommit. It will be pushed to remote successfully.