2

There is another question that describes my situation almost exactly (Git - Moving Pushed Commits to a Different Branch). The only difference is that the commits that I would like to move are in the Develop branch rather than master (which shouldn't matter because there's nothing special about the master branch). Also, we have redmine linked to our git repositories. Anyway, there was a comment by user Adam to the accepted answer:

Don't ever use push --force, it's a bad idea. It will seriously corrupt history on any other users who have already pulled. Even worse, if you have your Git log integrated into other systems such as Redmine, Jira, etc then it can seriously corrupt the databases and be quite difficult to clean up.

I wanted to reply to the comment to ask for clarification, but I had just created an account for this problem and don't have enough reputation points to post a comment. In my situation, there is only one other developer working on the project, so I'm not worried about corrupting the history of others. The thing I'm concerned about is what should be done about the 'even worse' case? I'm hoping that it might be okay in my situation because there haven't been any redmine issues entered after the first commit that needs to be moved (commit C in the above referenced post). I'm not sure though, because I don't know what all could get screwed up in redmine if a repository's history is rewritten.

I was thinking about it as I was searching for an answer, and I think I might have an alternative solution (I'm not confident enough in my git knowledge to post it as an answer, though). What if I rename Develop to NewBranch and then create a new Develop branch off of commit C?

# rename branch
git branch -m Develop NewBranch     # Rename locally
git push origin :Develop NewBranch  # Delete remote Develop branch & push NewBranch
git push origin -u NewBranch        # Reset upstream branch

#create new Develop branch
git checkout -b Develop $SHA1_OF_C
git push -u origin Develop

It seems like this would work. Are there any gotchas? What would the history look like? How would this affect redmine (aside from maybe having to change the default branch to the new Develop)? I think that It would look identical to what I want, except that it would show Develop branching off of NewBranch instead of the other way around.

Community
  • 1
  • 1
jhedges8
  • 21
  • 3

2 Answers2

0

The all problem here is the integration of Redmine with Git on the server side (otherwise, force pushing is perfectly OK, porvided the other users are notified and can reset their own local branch to the new remote one)

As an illustration of this problem, you have Redmine issue 9897: " Git: revisions and branches deleted in Git repository are shown in redmine".

There is a request for enhancement discussed for the past 8 years in Redmine feature 1273...

A much more sensible way would be to have Redmine allow changing commit messages through the REST API.
Then, post-commit hooks can be set up in version control so that only the single changed commit message is modified, instead of deleting and re-importing the whole history.

Sadly, the rest API is not complete enough to allow this kind of SCM-related operation.

I would simply create a new branch, cherry-pick the right commit on it and push said new branch.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • It's not just 1 commit, but a long series of commits starting at C. I'd like all of them to be moved from Develop to NewBranch. It seems like rebasing would be preferred over cherry picking. Don't both of those just copy the commits, though? How would I remove the commits from Develop while keeping redmine happy? I know I could just do a revert commit, but I'd really like all those old commits to go away. As for issue 9887, are you implying that if (after creating NewBranch) I checkout Develop, reset the head to commit C, and then force push it, that redmine will still show those old commits? – jhedges8 Oct 15 '16 at 15:26
  • You can cherry-pick a range of commits – VonC Oct 15 '16 at 16:12
  • And yes, that is the Redmine problem – VonC Oct 15 '16 at 16:12
  • @jhedges8 for cherry-picking a range of commits, see my old answer http://stackoverflow.com/a/1994491/6309 – VonC Oct 15 '16 at 18:23
0

My suggestion is to cherry-pick your commits to a new branch rather than renaming the existing branch.

Then you will be able to push that branch to remote without force push it.

git branch -b BRANCHNAME #Create new branch
git cherry-pick HASHVALUE #Cherry pick all the commits one by one. (eg: HASHVALUE - 5e2ld9)
DilumN
  • 2,889
  • 6
  • 30
  • 44
  • I did suggest exactly that in my answer – VonC Oct 15 '16 at 08:12
  • 1
    cherry-pick accepts range of commits you can just do `git cherry-pick HASHA..HASHB` where HASHA is the commit ID of point where the branches have diverged and HASHB is the top commit of the branch – Vlad Apr 16 '20 at 22:42