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.
Related
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.
This is my first time using github and I was having trouble with some of the commands and committed the same thing about 7 times through terminal. I don't know how this is possible because I thought you could only commit if there are changes made in the file. I wasn't seeing anything every time I committed so I kept deleting and remaking the same repository with the same name and tried committing over and over until I finally saw them now but theres too many I just want to see 1 initial commit not all 7. I want to know if there is a way to delete a commit if I have my github account open in my browser not by using terminal.
Note on possible duplicate: Please do not mark question as duplicate. I know there are similar questions/exact same questions asked. However I have read those and most of them are commands you have to type in the terminal and because there is no way to undo that I would prefer to do this through the website. I don't want to accidentally delete something I want and not be able to get my work back later. If there is something else I can use rather then terminal I would prefer to use that instead.
If you push your commits then I'm afraid there's no way to delete them. But if you haven't pushed your commits to the remote repository, then you can change the HEAD to the previous commit.
If you had pushed your commits in a branch, and then delete the branch without merging it with any other branches (you can not delete the default and protected branches), then technically the commits will also be deleted.
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.
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 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.