Issue with git squashing.

Hello, A brief background before explaining my problem: 1 I have enabled again the test cases regarding the allergy (add, delete, edit). They work fine locally. 2 I committed them on my local repository (git add, git commit). Successful commit. 3 Then aligned my local repository with the upstream (git fetch + git merge). Alignment was ok, only the pom.xml was updated. 4 I republished the last modification (git add, git commit). Successful commit. 5 I pushed my commits on my public (forcked) repository. It went fine and github said to me This branch is 2 commits ahead of openmrs:master. 6 I pulled a request from github then @dkayiwa, asked of me that I squash my last commits. 7 I squashed them ( git reset --soft HEAD~2). Then I tried to commit (as far I remember) I got a message like your local branch is 1 commits ahead and 2 commits beyond the master (not sure about the content). From now on, I’ve started troubling 8 I made a pull request (git pull --rebase upstream master) 9 I tried to squash again, repeated steps 7-8-9 more times. At the end, I found my public repository 5 commits ahead of master. I apologize for the huge mess. Now, I’m asking help. My idea to restore my repository is: a) git reset --hard 5f02af45cffbd3960132710b1953aea9cf951c64 (back to my first commit when I had fixed the tests) b) git pull --rebase upstream master (realignment with the upstream) c) git push --force (realignment with the public repository) d) hopefully, I see a message This branch is 1 commits ahead of openmrs:master on github, I will do another pull request in order to integrate my commits with the upstream.

I don’t know if it works any clue is more than welcome. Thank you in advance.

I also add the git logs for who might be interested in: 3c94550 HEAD@{0}: pull: Merge made by the ‘recursive’ strategy. 94c9551 HEAD@{1}: rebase -i (finish): returning to refs/heads/master 94c9551 HEAD@{2}: rebase -i (pick): Updating to the latest platform release 88013b9 HEAD@{3}: rebase -i (pick): [Maven Release] Increasing version of appointmentschedulinguiVersion to 1.5.1-SNAPSHOT 5f02af4 HEAD@{4}: rebase -i (start): checkout HEAD~2 d72dd8f HEAD@{5}: pull: Fast-forward 0565beb HEAD@{6}: reset: moving to HEAD~2 d72dd8f HEAD@{7}: pull: Fast-forward 6922356 HEAD@{8}: reset: moving to HEAD~2 d27ddb5 HEAD@{9}: pull: Merge made by the ‘recursive’ strategy. eb582cf HEAD@{10}: commit: The bug in RA-1253 has been fixed, therefore the tests has 6922356 HEAD@{11}: reset: moving to HEAD~2 eb9bcb6 HEAD@{12}: pull: Merge made by the ‘recursive’ strategy. 10c3378 HEAD@{13}: rebase finished: returning to refs/heads/master 10c3378 HEAD@{14}: pull --rebase upstream master: The ignore annotation has been removed since bug fixig RA-1253 6922356 HEAD@{15}: pull --rebase upstream master: checkout 6922356ec3e9cb45a3c6af8fe5c262f17de6d4e3 d72dd8f HEAD@{16}: merge upstream/master: Merge made by the ‘recursive’ strategy. 5f02af4 HEAD@{17}: checkout: moving from master to master 5f02af4 HEAD@{18}: commit: The ignore annotation has been removed since bug fixig RA-1253 0565beb HEAD@{19}: clone: from https://github.com/DomenicoDiLeo/openmrs-distro-referenceapplication.git

Hello @domenico, I think this will help StackOverflow thread is what you need If I understand your question well :slight_smile:

Hi @domenico,

Below is what would have gotten you to the pre-squashing popup:

git rebase -i HEAD~2 # So 'rebase' not 'reset'

Is the branch with your two commits still viewable somewhere? I would expect finding on your fork a branch named as per the ticket you’re working on, but I don’t see any…

@mksd I used the commands available here to squash the commits.

I didn’t create a new branch on my public repository because I wasn’t aware of openmrs development policy. Thank you both for the answers :slight_smile: @grimm, you understood my question, the link was fine.

I guess, I might work on this way:

a) git revert --no-commit 5f02af45cffbd3960132710b1953aea9cf951c64 HEAD (back to my first commit when I had fixed the tests and I don’t loose the commits history) b) git pull --rebase upstream master (realignment with the upstream) c) git push --force (realignment with the public repository)

What do you think of?

Naming a branch after the issue code is not a policy, it’s rather a common practise. There’s no obligation at all! :wink: But if you see, in some repo, a branch named after an issue code, it’s clear that it holds the work in progress to fix that issue. You may just ignore this tip completely and you remain free to name your branches whatever you find meaningful/useful.

I wasn’t aware that you were following that wiki article. It illustrates yet another way to squash. What I pointed you to goes the other way around: you would commit as many times as you want. And then you would rewrite the commit history by collapsing multiple commits into one. That’s how I squash and I’m sure there’s a dozen other ways of doing it.

You seem to describe steps to rebase your branch on upstream/master, which you need to do of course but that’s a different question from squashing commits. You can do things in both orders: rebase on upstream first, then bring in multiple commits and finally squash them. Or the other way around: your commits are on your out-of-sync branch, you squash them and then you bring your one commit onto master. Both will leave you in a one commit ahead of master situation ready to be PR’d.

1 Like

@mksd Yes indeed branching after issue code, it is a general approach :slight_smile: Now that I had problem with the squash, I’m trying to recover “my code base” and trying to do the thing in the “best way” possible or at least I don’t want to create other chaos. I wanted to revert the 5 commits on my public master that make it ahead of the upstream as first, but maybe, if I got your point, I can try to git rebase upstream master git commit and then squashing I have some doubt that after the rebase I can commit. I’ll keep you posted. Thank you very much.

Actually the most important thing in all this is that you safely keep somewhere, on some branch, the sequence of commits that represents your work. That’s what you must not loose. I would say: keep that one and start doing Git specific work on other branches (possible temp branches) that you start off the tip of that one.

Precisely ‘git pull --rebase’ will sync whatever you are on with the upstream. You will use this when you deem necessary depending on the sequence of events that you choose from (see my last message).

By keeping the ‘original work branch’ and doing whatever else on other branches created off it, you allow yourself to start over again safely as many times as you need. Basically I just Git-advised you to keep a copy of your work before doing anything else :wink: