• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Rob Spoor
  • Henry Wong
  • Liutauras Vilda
Saloon Keepers:
  • Tim Moores
  • Carey Brown
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Frits Walraven
  • Himai Minh
  • Jj Roberts

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

 
salvin francis
Bartender
Posts: 2845
150
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 : 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:
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:

See attached screenshot. I have seen similar results with IntelliJ and SourceTree as well.

Maybe I am doing something wrong here ?
Eclipse-rebase-flow.gif
[Thumbnail for Eclipse-rebase-flow.gif]
 
salvin francis
Bartender
Posts: 2845
150
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:
    Selecting the second option gives:
    IntelliJ.gif
    [Thumbnail for IntelliJ.gif]
     
    salvin francis
    Bartender
    Posts: 2845
    150
    Google Web Toolkit Eclipse IDE Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Source tree follows the same suite and asks me to do a pull before a push.

    Am I doing something wrong ?
    Source-Tree.gif
    [Thumbnail for Source-Tree.gif]
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 12811
    278
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Bartender
    Posts: 2845
    150
    Google Web Toolkit Eclipse IDE Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Saloon Keeper
    Posts: 12811
    278
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Saloon Keeper
    Posts: 23409
    159
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Bartender
    Posts: 2845
    150
    Google Web Toolkit Eclipse IDE Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Eclipse-Rebase.gif
    [Thumbnail for Eclipse-Rebase.gif]
    SourceTree-Rebase.gif
    [Thumbnail for SourceTree-Rebase.gif]
     
    Tim Holloway
    Saloon Keeper
    Posts: 23409
    159
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Sheriff
    Posts: 7950
    549
    Mac OS X VI Editor BSD Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Cowgratulations, your post has been published in CodeRanch's August 2020 journal.
    Staff note (Liutauras Vilda) :

    @OP

     
    salvin francis
    Bartender
    Posts: 2845
    150
    Google Web Toolkit Eclipse IDE Java
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks for the cow and featuring this post !
    The git game is amazing and brought me up to speed with a lot of things.
     
    That is a really big piece of pie for such a tiny ad:
    SKIP - a book about connecting industrious people with elderly land owners
    https://coderanch.com/t/skip-book
    reply
      Bookmark Topic Watch Topic
    • New Topic