This question already has answers here:
How to retain commit gpg-signature after interactive rebase squashing?
(4 answers)
Closed 2 years ago.
The community reviewed whether to reopen this question 12 days ago and left it closed:
Original close reason(s) were not resolved
All commits that have been pushed to the develop branch indicate that they were verified.
To merge everything from develop to master, I decided to click a button Rebase and merge. (I didn't want to create another new commit for the master.)
Surprisingly after the merge succeeds, all the verified signatures were gone from the master.
What am I missing here?
How am I supposed to preserve the verified signature?
When rebasing the changes are replayed on master. This causes them to be "rebased" on a new parent commit which will change the commit-id (which is partially based on the parent commit-id).
Rebasing may also require merging the changes as the commits are replayed. Even if the merge happens automatically, it may change the contents of the files. The file contents are another element that make up the commit-id.
The verification is done through a cryptographic signature of the contents and the commit-metadata. Hence, rebasing will break that signature.
To not break your signature you'll need to use a fast-forward merge (where no new merge commit is created). To achieve that you'll need to locally rebase your changes and sign them.
Or you can squash-rebase, where all your small commits are rolled up into a single new commit, which GitHub will sign on your behalf.
If verification is important to you, rebasing is generally a bad idea, fast-forward merges and merge commits will better reflect what actually happened and who had authored those changes.
Related
This question already has answers here:
How do I revert a Git repository to a previous commit?
(41 answers)
Closed 4 years ago.
I realize this isn't directly a coding question, but GitHub is widely used and I haven't seen how to do this, so I figured I'd ask as I'm trying to figure it out.
Using GitHub how do I go about backtracking a development branch to a previous push point?
For example, let's say I have a dev branch and I push faulty code, how do I backtrack to a previous point in that branch in the event I need to?
I'd prefer to see how to do this from the command line, but in the web UI is fine as well.
Assuming your branch with the bad commit(s) has already been published to GitHub, and other users may have already pushed it, then you typically would not literally rollback that branch. Instead, you would use git revert to functionally undo the bad commit:
git revert 1a7h3jxk # where 1a7h3jxk is the SHA-1 hash of the bad commit
git revert actually adds a new commit which functionally undoes the commit you specify as a parameter. It also allows syntax for specifying a range of commits.
If you really want to formally "backtrack" your branch, you could do a hard reset to remove the bad commit(s). For example, to actually remove a single bad commit you could do:
git reset --hard HEAD~1
git push --force origin your_branch
But note carefully that doing a hard reset means that you are rewriting the history of your branch. This means you have to force push (read: overwrite) the version of the branch on the remote. As mentioned above, this option should not be used if anyone shared this branch besides you.
This question already has answers here:
How to remove certain changesets from a specific Mercurial clone?
(4 answers)
Closed 4 years ago.
I have pushed two change sets on Mercurial and I wanted to delete them. I have checked How to remove changesets from a Mercurial repository?
but it seems it works with committed change sets only.
Thanks,
Nick
There is no ultimate answer to your question - and the answer may well be "there is no way".
The main questions are:
* Do you AND the remote repository use changeset evolution / are the commits still in draft phase?
If so: excellent. Just create and push updated commits which replace / obsolete the commits.
If not: Do you have access to that (remote) repository and can work on that?
Wonderful. Login to the remote machine (or the administrative web panel) and remove the unwanted changesets, e.g. be uncommit or rollback (only the last commit, not recommended).
If not: you have a problem. Contact the admin and ask them for that access. Maybe enable changeset evolution and remove with its tooling the questionable commits.
Also make sure you remove the exact same thing in your local repository.
As last resort: Use hg backout. That will not remove the commit. But will undo it by basically committing the reverse.
So I've got a long and detailed Mercurial Repository which has been worked on by several times over a long period of time with lots of branches, in that time no one knew that you can close a branch.
Recently I've closed nearly 1200 abandoned heads and it runs a lot better. However we have a number of branches which we want to preserve. Some I think may have already been merged back in to default but I'm not sure.
I can see if I run hg branches that they are marked as (inactive) meaning that it has been merged in to another branch but on checking its not merged directly back in to default. Is there a way I can check if somewhere these branches have been merged back in to default even if its via another branch ?
I believe you can accomplish that with revsets, in particular:
hg log -r "not ancestors(heads(default)) and head() and not closed()"
That should get you all heads of named branches that have not been closed and are not ancestors of (i.e. have not been merged into) the default branch.
I'm working with a github repo where a lot of commits historically have been "bugfix", "bugfix for real this time", "ok final bugfix", "finally fixed".
These were committed directly to master. How can I squash them?
Fromt his post a year ago - it basically sounds like this is bad, want to squash multiple commits in github. Has anything changed in the past year?
The answer today is basically the same: Squashing these commits is possible, but rewriting shared history is something to be strongly avoided in Git.
Imagine that you and I each have a copy of some repository that also exists on GitHub:
A---B---C
You notice that commits B and C should really have been committed together, so you squash these commits in your local copy. You now have
A---D
where D is a combination of B and C, while GitHub and I still have
A---B---C
At this point, even though the file content is the same everywhere, our commit IDs have diverged. Now you can't push to GitHub without --force, because GitHub's master branch contains two commits that are no longer present in your history.
If you do use --force you can make GitHub accept your changes, but now my repository contains commit objects that are no longer present upstream. I can't push to GitHub without using --force (which will invalidate your changes) or without doing a relatively funky merge to bring your changes in, probably rebasing my work, etc. And that's only possible if you communicate with me outside of Git to tell me what you've done.
This gets even messier with more developers (imaging doing this on the Linux kernel repository!) and with more work being done concurrently.
Really, any time you're tempted to git push --force, sit back and think for a moment. You're probably doing something that should only be done with an extremely good reason.
My recommendation is to accept that your history is a bit messy, but to try to improve things going forward. These commits can be cleaned up locally, before you push to GitHub (or share with other developers). Work in feature branches, use cherry-pick, rebase, etc. to clean up the commit history if necessary, then push.
Squashing is something which is used to merge a lot of commits into one. If you want to clean up last serval commit's check your last git log's by using
git log
this will look something like this
* df71a27 - (HEAD feature_x) Updated CSS for new elements (4 minutes ago)
* ba9dd9a - Added new elements to page design (15 minutes ago)
* f392171 - Added new feature X (1 day ago)
* d7322aa - (origin/feature_x) Proof of concept for feature X (3 days ago)
now if you want to squash last three commit's then
git rebase -i HEAD~3
by doing this you'll get into editor like this
pick f392171 Added new feature X
pick ba9dd9a Added new elements to page design
pick df71a27 Updated CSS for new elements
Edit the one who you want to squash like this
pick f392171 Added new feature X
squash ba9dd9a Added new elements to page design
squash df71a27 Updated CSS for new elements
When done, save and quit your editor. Git will now squash the commits into one. All done!
I am working with the GitHub GUI on Windows.
I did some work on my project which was successfully committed about a month ago going forward. Unfortunately other person who also works on this project recently committed the files I changed without realizing that he removed a huge portion of my work.
Now my question would be: is there an easy way of restoring my commits. This is not one commit. For the past month I made several very important commits to the project which got killed by the other party error.
I really don't want to go thru each file individually and re-aaply the changes manually, especially since I already got paid for that work.
How can I get my commits back?
IF you don't see your commit anymore in the history of the repo, that would mean the other developer has done a forced push (git push --force).
In that case, use git reflog (as in this answer) to find your commits back.
If yo do see your commits, then you could revert (git revert) the commits introduced by the other developers in order to cancel them, which should leave your branch in a state reflecting your work.
In both cases, this is a communication issue: you need to coordinate with the other developer in order for both of you to agree on a state from which to move forward.