What's the right way to do a rebase using an IDE ?

[salvin francis]

I've recently switched to a rebase workflow. While I know how it should work theoretically, in practice, I am not able to get it to work. My IDE of choice is Eclipse.
This is the setup I created :      F1--F2----F3 (feature)     / M1--M2------M3 (master)If my ascii design is not clear, M1 is the first commit to master, then M2. Now a feature branch is created from M2. Next, F1, F2 are committed. Then, someone commits M3 on master and finally F3 is committed on feature branch. This sequence is intentional

As per my understanding, after rebasing feature on master, this is what I expect:

M1--M2------M3-F1--F2----F3	(master/feature)

However, Eclipse does not do this. After Step 3. It does not allow the branch to be pushed. The only thing works is a Pull followed by a Push. However, this results an unexpected output:
     F1--F2--F3---------     /                  \ M1--M2------M3---F1--F2--F3 (master)
See attached screenshot. I have seen similar results with IntelliJ and SourceTree as well.

Maybe I am doing something wrong here ?

[salvin francis]

Here's my observations in IntelliJ (I haven't used this IDE too much). I couldn't find a push button anywhere in the UI. The only option I could see was Update.
Doing an update showed a dialog with 2 options:

Merge incoming changes into the current branch

Rebase the current branch on top of incoming changes

Selecting the first option gives a similar result to eclipse:
     F1--F2--F3-------------     /                      \ M1--M2------M3---F1--F2--F3-FMerge         (master)Selecting the second option gives:
      F1--F2--F3-----M3      (feature)     /                   M1--M2------M3               (master)

[salvin francis]

Source tree follows the same suite and asks me to do a pull before a push.

Am I doing something wrong ?

[Stephan van Hulst]

I didn't read through your posts very carefully yet, so maybe I'm misunderstanding the problem, but it appears that you seem to be confused that your push is rejected after a rebase.

This is normal and expected behavior. A rebase performs history rewriting. Essentially you take old commits and replace them with new commits. A central theme in Git is that no matter what you do, you never lose history. Rebasing goes against that principle.

Git usually requires you to use a 'force' command line option to perform actions that rewrite history. It doesn't do this for rebasing, presumably because it's a natural operation to want to use. This is fine as long as your commits haven't been pushed to the origin server, but once you try to rebase commits that have already been pushed, the server will reject your push because you're telling it to drop commits that may already have been pulled by other users.

If you really want to rebase commits that have been pushed, I think you have two options: Either you 'force push' your rebased commits, or you configure the origin server that it doesn't complain about history rewriting.

[salvin francis]

Stephan van Hulst wrote:... it appears that you seem to be confused that your push is rejected after a rebase.

That's correct.

Stephan van Hulst wrote:This is normal and expected behavior. A rebase performs history rewriting. Essentially you take old commits and replace them with new commits. A central theme in Git is that no matter what you do, you never lose history. Rebasing goes against that principle.

This is what makes things clear. Thank you. I feel bad that I have not even explored this rebase option after years of using git for a merged based workflow. My thought process was that it should have worked as a simple push. I stand corrected.

Following the force option, I was able to to get it to work as desired (And learned something new along the way!!). Will post screenshots soon.

[Stephan van Hulst]

Have you performed the "Git game" yet? It's great even if you're already familiar with most of Git's common operations: https://learngitbranching.js.org/

Merge-based workflows should be the norm. Rebasing is great when you're working on a small feature or bugfix branch by yourself, but as soon as more than one person works on the same branch, rebasing should no longer be used on pushed commits.

If you want a clean commit history on your dev/master branch, you can do two things:

For small features or bugfixes, use "squash merges" when you merge the feature branch to your dev/master branch. This will squash all unmerged commits on the feature branch into a single commit, which will then be merged.

For large features, first create a "staging" branch from your feature branch containing the commits that you want to merge to master. Use interactive rebase on this branch to shape the commit history of the feature. When you're happy with it, merge it to master.

In both cases, make sure to delete the feature branch to prevent other people from basing their work on old commits that won't be merged to master (because they were squashed/rebased).

[Tim Holloway]

Truthfully, I tend to avoid using the IDE to do complex and abstruse VC operations. The menus are typically designed using different (and often more abstract) language than the command-line manuals and examples use.

So when I'm doing something that can potentially mangle a repository, I prefer to use the command-line interface and a good tutorial.

[salvin francis]

Stephan van Hulst wrote:Have you performed the "Git game" yet?

I'll try it out. Seems fun !!

Stephan van Hulst wrote:Merge-based workflows should be the norm. Rebasing is great when you're working on a small feature or bugfix branch by yourself, but as soon as more than one person works on the same branch, rebasing should no longer be used on pushed commits.

Agreed. This is indeed my current work scenario. We do squash all our commit and delete the feature branch when merged.

Tim Holloway wrote:Truthfully, I tend to avoid using the IDE to do complex and abstruse VC operations...

I have mixed feelings about this. I think the commands are a bit confusing and I've liked the UI for merge based workflow. But, I will try and learn the commands soon.

For others reading this post, here's what worked for me:

Source Tree setup:

Go to Tools > Options > Git

Ensure that "Enabled Force Push" is checked. By default, this is unchecked

It's also advisable to set "Use Safe Force Push (--force-with-lease)" to checked.

Source Tree Steps (See attached screenshot):

Talk to all team mates and ensure that no one is working on the branch you want to rebase

Right click the branch you want to rebase on (typically master) and select "Rebase..."

Click okay on the Confirm Rebase dialog.

UI does the rebase and if there are no conflicts, it will show some numbers against Push and Pull

Click Push (Do not go for the Pull first like I did previously )

In the Push dialog, check "Force Push" and click Push

UI will warn you against the Force Push. Click Yes to continue

Voila !! A straight line of commits !

Eclipse Steps (See attached screenshot):

Talk to all team mates and ensure that no one is working on the branch you want to rebase

Right click the branch you want to rebase on (typically master) and select "Rebase HEAD on"

UI does the rebase and if there are no conflicts, it will show some numbers incoming and outgoing in project explorer

Right click Project in Project Explorer > Team > "Push branch '<your branch name here>' ..."

In the Push dialog wizard screen1, select "Force overwrite branch in remote if it exists and has diverged". Click Preview >

In the Push dialog wizard screen2, select "Cancel push if result would be different than above because of changes on remote". Click Push

Voila !! A straight line of commits !

I think that "Cancel push if result would be different than above because of changes on remote" is "--force-with-lease" as mentioned here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=539875

Couldn't figure out how to do it in IntelliJ

[Tim Holloway]

Well! I hadn't known about the pretty graphs. I can see their appeal. In my defense, I should mention that the majority of what I'm using git for these days is to keep repositories of configuration data for non-GUI servers. So often command-line is my only (or at least preferred) interface. And the Git online docs are generally pretty illustrative. But I do like how easy Eclipse has made it to browse history.

I have a lot of activity on some of those archives, so I was concerned about resources. But it turns out that Git is remarkably frugal in its disk space usage, so I've resisted the impulse to squash anything just to save space.

On the other hand, if I wanted to simply consolidate changes into fixed releases, I think I'd probably keep a separate production repo, and update it periodically from an exported reference head of a test repo. Not having done this I don't know if that's any better or not.

[Liutauras Vilda]

Cowgratulations, your post has been published in CodeRanch's August 2020 journal.

[salvin francis]

Thanks for the cow and featuring this post !
The git game is amazing and brought me up to speed with a lot of things.