Problems with reseting the git cherry-pick

I made some code adjustments to evaluate some functionality in our software. This changes were made to a version of software let say dev_1. We have the official version of the software in CVS, so I checked out dev_1, initiated a git repo and made a few commits. Now my colleague comes and say “hey, I made some adjustment in the algorithm and I would like to know how your evaluation looks like with my version of the code, my version is in CVS ad dev_2.”

So I checked out dev_2 from CVS and intialized the git repo. Now I need to apply my changes that I made to dev_1 to dev_2. I decided to cherrypick the commits from dev_1 repo and apply them to dev_2.

  • which commit was cherry-picked?
  • Is it possible to apply a commit to all branches in git?
  • Git: move changes between branches without working directory change
  • Git - Is cherry-picking a bad practice if I want to have a consistent workflow?
  • How does git merge after cherry-pick work?
  • How to preserve original author on cherry-pick smartgit
  • However I made some error during cherrypicking merge and now my dev_2 working directry seems to be changed and I don’t know how to get to the state where it was before I attempted to cherry-pick.

    Is there some way, how to get to the state before cherry-picking?
    What is a difference between cherry-pick –abort and cherry-pick –quit (none seems to help)?
    And finally, do you think that may approach to solve this problem is good or is there some more simple approach?

    Thank you

  • Changing commit metadata on all commits
  • gitlab-shell -> git push -u origin master -> fatal: The remote end hung up unexpectedly
  • GitHub for Mac crashes on open because of local repository issue
  • What pull requester should do to revert bad commits
  • Git oddity with folders between branches
  • How to version-control spread-out files without replacing the originals?
  • One Solution collect form web for “Problems with reseting the git cherry-pick”

    First do git status to verify the state. Closely inspect what it prints.

    • If it tells you you’re on a branch “master” just have some werid (for you) state of files, do

      git reset --hard

      to revert the index and the work tree back to the state of the tip of the checked out branch “master”.

    • If it tells you you’re in a “detached HEAD” state, do

      git checkout master

      and then proceed as in the first case.

    More info on resetting is in the great “Reset Demystified” article.

    Git Baby is a git and github fan, let's start git clone.