2

I recently cloned my application from Bitbucket and checkout to a new upgrading branch where I upgraded my application from rails 5.0.0.1 to rails 5.1.6:

$ git checkout -b upgrading

I firstly updated my Gemfile, the I ran bundle update:

$ bundle update

From the railsdiff website and from a new rails 5.1.6 application created for the purpose, I edited my old application adding or removing code and deleting or creating files, and I edited the migration files specifing a version of the class to inherit from. Then I committed my application with git before running rails app:update:

$ git add -A
$ git commit -m 'before rails app update'
$ rails app:update

There were few changes to make, then I reset my database and ran my entire test suite:

$ rails db:migrate:reset
$ rails test

I seeded the database, launched the server and test the application graphically. Everything was fine. Finally I made a commit, switched to the master branch, squash merged the upgrading branch and finally made one last commit:

$ git add -A
$ git commit -m "work in progress"
$ git checkout master 
$ git merge --squash upgrading
$ git commit -m "upgrade to Rails 5.1.6"
$ git push

Everything was fine, except when I tried to delete the upgrading branch, because the operation failed:

$ git branch -d upgrading
error: The branch 'upgrading' is not fully merged.
If you are sure you want to delete it, run 'git branch -D upgrading'.

I know only few git basic commands, so I have no idea why this happened. I would appreciate any help.

Asarluhi
  • 1,280
  • 3
  • 22
  • 43

3 Answers3

6

The problem is that you merged your upgrading branch into master with --squash. Squashing commits on the upgrading branch leaves you with a new sha for the commit. Because of this new sha, git is unable to detect that this branch was merged with master, and believes that it wasn’t. Instead of squashing your merge, you could rebase your upgrading branch to all be 1 commit and then merge that to master without a squash.

This would result in a single commit being merged to master still, except git would be aware of the fact that the branch was indeed merged as the branch’s sha is actually in master’s history, and it won’t have a problem with you trying to delete the upgrading branch.

If you’re 100% sure that master does have the changes from the upgrading branch, then just use git branch -D upgrading to tell git that you’re really sure you want to delete that branch.

If you’re wanting to bring your upgrading branch in sync with master before merging, and also squash the commits down to one in the process, you can do:

git rebase -i master

And then you can choose what you want with your commits. You can squash, pick, fixup, etc. This will leave you with a tidy upgrading branch that can be merged into master without problem.

Nate
  • 2,364
  • 1
  • 10
  • 16
3

Not too much of a concern, if I may.

git branch -d is the "shy" delete mode, extremely cautious about anything possibly being lost. With the operations you described, no work will be lost since all the branch's commits are on your master now (even if they're squashed).

That being said, a branch is not a big burden, the cost of keeping it "just in case" for later use (since you squashed your commits and might want to inspect individual steps for bug resolution at a later point) is probably very low in terms of disk space.

You could also put a tag* on the tip of the branch, delete the branch**, and you'll have these unsquashed commits available for further inspection (which, again, has said disk space cost, but is maybe clearer if you want to have your branch list void of any finished work).

* with git tag before-the-squash upgrading
** with git branch -D upgrading

Romain Valeri
  • 19,645
  • 3
  • 36
  • 61
  • Is there any way, as far as you know, to ask git to report what was not merged? If git says that the branch is not fully merged it means that something was not merged. Would you re-merge the same branch? – Asarluhi Mar 31 '19 at 15:27
  • 1
    @Asarluhi No I would not, and if you tried it would end up an empty merge, since the codebase is now similar on both branches. The detection happens at commit level, and since you squashed your commits, they don't appear as such on master. – Romain Valeri Mar 31 '19 at 15:29
  • What do you mean with "putting a tag on the tip of the branch" before deleting it? Still, there should be a way to ask git to report what was lost during the merging of the upgrading branch in the master branch. – Asarluhi Mar 31 '19 at 15:40
  • 1
    @Asarluhi Nothing was "lost" in terms of file contents. What is detected by `git branch -d` as a flag for "caution : possible loss" is the comparison of the commits reachable from either point. And *this* has changed, although it's irrelevant in terms of content. I know this is troubling at first, but diff your branches to be convinced : no diff. – Romain Valeri Mar 31 '19 at 15:43
  • 1
    @Asarluhi About the tagging process : just `git tag before-the-squash upgrading` (I've edited above) – Romain Valeri Mar 31 '19 at 15:45
  • I found in an old topic that the warning might be due to the `--squash` option, to git comparing the commits in the topic branch with the commits in the master branch: https://stackoverflow.com/a/41947745/5078888 – Asarluhi Mar 31 '19 at 17:37
1

Git is trying to protect you from losing everything you worked on... Git detected that you did not merge the work you did on this branch (upgrading)

But, as you said, you want to delete because the process failed. So, that means you sure you want to delete it, and loose everything you did there.

For this git also says how to do it. Just run:

git branch -D upgrading

  • with capital D
WeezHard
  • 1,982
  • 1
  • 16
  • 37