I worked on a branch in my Rails app, committed, and merged it into my master, because I was happy with everything, but now I want to take out that branch again and discard those changes.
Is it possible or too late now that I have merged the branch with the master?
Thanks
Once you have pushed commits to a central location, it's best not to modify them in any way.
An alternative is to generate a reverse commit. That is, a commit that undoes all the changes in a previous commit. One way is git-revert. Assuming that you've merged in commits <sha2>, <sha3> and <sha4>, you could:
git revert <sha4>
git revert <sha3>
git revert <sha2>
If you'd like to revert all changes in a single commit, try the --no-commit option:
git revert --no-commit <sha4>
git revert --no-commit <sha3>
git revert --no-commit <sha2>
git commit -m "Undid feature merge"
Another way to generate a single reverse commit is git checkout:
git checkout -f <sha2>
git commit -a -m "Undid feature merge"
You could do a git reset. This is fine if it was only a recent local merge.
If you already pushed the merge somewhere or you have more commits on top, this is no good idea. Instead you have to accept your merge and do a clean git revert. This way the history still contains the merge but the revert will undo the effect of the merge.
Related
When using Gitlab or Github to manage code, after merged a merge request or pull request for dev to master, the HEAD of dev always fall behind HEAD of master one commit because of the default merge command is git merge with --no-ff.
How to make HEAD of dev to be the same as HEAD of master?
I find some command online:
git checkout dev
git merge master --ff-only
Is it right? Is it reasonable to merge master into dev?
You should never merge public branch into your own feature branch.
Try git rebase master
I executed 31 grafts to a local branch and want to strip out 2 of the grafts. The problem is that the 2 grafts are somewhere in the middle, number 5 and 23 out of 31.
What do I execute to strip out these grafts? Also, is it possible to just strip out those 2 grafts specifically and not strip out subsequent grafts?
Thanks
You can do this with the evolve extension. Here are the evolve docs. It is a sharp knife, but a really user-friendly one. Main advice: don't use it on changesets that you already pushed. Let's repeat that:
Assumption: you have not yet pushed any of the changesets you are about to remove, nor any of their descendants.
Check that assumption. Do (if 4 is the number of the earliest changeset you want to prune):
hg log -r 'descendants(4)' --template '{rev}: {phase}\n{desc|firstline}\n'
This prints each changset, followed by its phase, and the first line of its commit message.
None of the phases should be public; all of them should be draft. (Or secret, but if you know about the secret phase then you clearly understand phases.)
Another assumption:
hg log --version
# Should be at least 3.4
Installing hg-evolve
Instructions taken from the wiki. First, clone the evolve repository, and checkout the tag corresponding to whichever version of mercurial you are running. There are tags for 3.4, 3.5, 3.6, 3.7, and 3.8. Ubuntu Xenial ships with Mercurial 3.7.
cd <dir>
hg clone https://www.mercurial-scm.org/repo/evolve/ --updaterev mercurial-3.7
Then edit your .hgrc:
[extensions]
evolve = <dir>/src/evolve-main/hgext/evolve.py
Work in a clone, just to feel safe
For your peace of mind, do this in a clone. To make sure the cloned changesets remain in the draft phase, set your current repo to be non-publishing before pulling from it; otherwise the commits that get cloned will be marked as public on both server repo (the one getting talked to) and client (the one running the clone/pull/push command). The Evolve extension will only alter parts of the history tree that consist of draft changesets.
Mark the server repo, i.e. the one you're currently working on, as non-publishing, in its hgrc:
cd my-project
hg config --local
In the repo's hgrc:
[phases]
publish = False
Next, create the clone.
cd ..
hg clone my-project my-project2
cd my-project2
Tell hg to prune the changesets and repair history
hg prune -r 23
This will make all changesets after 23 'unstable', because they are now based on a revision marked obsolete. You can see the new state of the history like so:
hg log --graph
The obsolete commit 23 will be marked with an x.
To fix the instability caused by modifying the history, run
hg evolve
Which will
take the first unstable changeset (24),
create a stable successor of 24 atop 23's successor -- because 23 was pruned, 24 will be moved atop 22. 24's successor will be e.g. 32.
mark 24 obsolete.
If there are merge conflicts because changeset 24 assumed context that was provided by 23, you will be prompted to resolve the conflicts.
Then, run hg evolve again; which will create a successor of the next unstable changeset in the right place (25 was atop 24; 24's successor is 32, so create 33 atop 32).
Run hg evolve again and again until all unstable changesets have been resolved. Once you feel confident that hg evolve does the right thing (it does), you can run hg evolve --all to move them one after another until there are no unstable changes left.
Now, the obsolete changesets will be automatically hidden: there are no non-obsolete changesets that depend on them anymore.
hg log --graph # hides obsolete commits if they are irrelevant
hg log --graph --hidden # also shows all obsolete commits
Once you're done with that, you can remove commit 4 in the same way:
hg prune -r 4
hg evolve --all
If you want to see your history including obsolete changesets
hg log --graph --hidden
Get your changes back to your main repo
In the my-project2 repo, just push your changes back
hg push
This will push the new successors commits back to my-project. It will also push the obsolescence markers of the ones that were pruned or replaced by a successor.
Clean up
delete the my-project2 repo (unless you want to keep it around)
configure my-project as publish = True again (unless nobody but you pulls/clones from it)
Decide whether to keep hg-evolve in your extensions. Core Mercurial understands obsolescence markers, so you're safe, there -- you can even use hg log --hidden. On the other hand, if evolve is not active and there are obsolescense markers in your repo, you'll sometimes (like when you run hg log) get a warning like obsolete feature not enabled but 5 markers found!
If you do a rollback in Heroku it will checkout a previous commit on the Heroku side. We know that. However, how do you restore it to the HEAD commit?
It seems that you actually have to modify your local HEAD, and then push to the repository. Otherwise,
$ git push git#heroku.com:appname.git HEAD:master
Everything up-to-date
and nothing happens, i.e. no new release is created.
The easy solution is just to do some innocuous change like a bundle install, commit, and push. But I was hoping to find someway to bring apps up to the HEAD if they weren't before. Any insight? Am I missing something?
When you do a rollback, you're creating a new deployment to an older change #. The other version is still out there in git. So to go "forward" to the newer change, you'd roll back again, this time to the deployment at that hash number.
When I sync from the ToolTwist Designer, I select the files I wish to publish, but I get an error when I press OK, saying that the sync failed and to look in the server log file.
If I try again, the files I selected are no longer in the list, but if I check Git I can see they are not pushed to the repository.
In the log file I see that the push failed, and if I go to the webdesign directory and test the push command I get the same error:
$ git push --dry-run
To git#github.com:MyRepository/design-project.git
! [rejected] master -> master (non-fast-forward)
I'm using the 'design' branch, so I'm not sure why an error is occurring on the 'master' branch.
In normal circumstances the Designer only uses a single git branch, normally named 'design'. The error message above indicates a conflict on the master branch.
It appears that changes have been committed to the master branch on the local machine but not pushed, whilst elsewhere changes have been committed to the master branch and have been pushed onto the remote repo.
To clear this conflict you'll need to checkout the master branch and do a pull to merge in the changes on the remote, and then the next push will work. Don't forget to change back to the design branch when you're finished.
[stop the Designer]
$ git checkout master
$ git pull
[resolve any conflicts]
$ git push origin master
$ git checkout design
[start the Designer]
By default git tries to push commits on all branches. In this case, you might find that the conflict on the master branch is preventing your web design changes on the design branch from being committed. To prevent this from happening, you can configure git's default behaviour to only push the current branch.
$ git config push.default current
You might also want to investigate why the master branch is being changed (and in two locations).
In my company we have a subversion server and everyone is using subversion on their machines.
However I'd like to use git, committing changes locally and then "push" them when I'm ready.
However, I can't understand what happens in the following situation.
Let's say that I made 3 git commits locally and now I'm ready to "push" everything on the subversion server. If I understand correctly, git svn dcommit should basically make 3 commits sequentially on the server, right? But what happens if in the meantime (let's say between the second and the third commit) another colleague of mine issues a commit?
The scenarios I can think of are:
1) git kind of "locks" (is that even possible?) the subversion server during commits so that my commits are doing atomically and my colleague's one is done after mine
2) The commit history on the server becomes mine1-mine2-other-mine3 (even if 'other' should fail since my colleague doesn't have an updated working copy at that point).
I think it's #2, but perhaps the committing speed is so high that this seldom becomes an issue. So which one is, #1 or #2?
No locks are not supported in Git, it's not a Git way (Git way is branching and merginig).
With git-svn you'll get mine1-mine2-other-mine3 history. If you need atomicity, have a look at SubGit project (it is installed into the SVN server and creates a pure Git interface for the SVN repository).
There was a similar question recently that might be interesting for you.
If you are lucky then number 2 but most of the time you aren't that lucky. In my experience when I dcommit a lot of commits and someone else commits while doing that usually 2 things happen:
It stops with dcommitting your other changes.
You lose the commits not-yet dcommitted.
Number 2 is really really annoying. The main problem is that you need to be totally up-to date to use git svn dcommit. This is because git-svn doesn't let the server merge revisions on the fly. (Because it would require both committers to have a working tree with both changes).
The only way to solve this are the following steps which I found here
Open .git/logs/HEAD
Look for your most recent commit (note that these commits are sorted
by “unix time”, although you can also find the latest one by reading
the shortlog there
Confirm that the commit you found is the right one: git show
git reset --hard hash from log
git svn rebase
git svn dcommit
Following this procedure allows you to take off from where it failed. I hope they fix this soon but they said this isn't priority for them yet.
Ofcourse if you commmit small groups and have a fast connection to the server it shouldn't happen that often. (I only got it 2-3 times when actively working and committing every day for 6 months).