From: David Gudeman 
  Cc: Philip Oakley 
  Sent: Sunday, June 16, 2013 11:31 PM
  Subject: Re: [git-users] what is the point of rebase?

  Thanks for taking the time for such a detailed reply, Philip, but everything 
you say seems to be true of merge as well so I still don't get what is special 
about rebase. Is it just merge+throw away history? And if so, why throw away 
the history rather than just hide it?

  On Thursday, June 13, 2013 12:31:07 PM UTC-7, Philip Oakley wrote:
      From: David Gdeman
      Sent: Thursday, June 13, 2013 7:12 PM
      Subject: [git-users] what is the point of rebase?

      I've been getting to know git recently as part of some work I needed to 
do, and I love the easy branching and merging, but I have to admit that rebase 
is confusing me. I'm not confused about what it does (I don't think); I'm 
confused about what the point is. As far as I can tell, rebase is just the same 
as doing a merge and then throwing away some history. Why throw away the 
history? All of the documentation I can find just refers to making history 
"clean", but the history doesn't have to actually BE clean to LOOK clean. So 

      Or here is another way to ask the question. Suppose git repositories had 
a special flag that you could put on a branch that said, "don't show this 
branch in histories or push it or allow it to be pulled unless the user does 
something special to ask for hidden branches". Then suppose git had a 
merge-and-hide command that would do a merge and then set this flag on the 
topic branch to effectively hide it unless the user really wants to see it. 
What does rebase accomplish that merge-and-hide would not?

      I keep feeling that there must be something else, otherwise why deal with 
the potential negative consequences of deleting history unrecoverably? All of 
the documentation on rebase talks about the problem of rebasing a branch out 
from under someone who is still working on it. So what is the advantage of 
rebase over merge-and-hide that makes it worth dealing with this problem.
    Rebase is a way, within a distributed system, of noticing that the world 
has moved on since you started on your magic topic branch. 

    So you want your magic topic branch to cleanly apply to the New World Order 
of the upstream repo, hence you 'rebase', or transfer, your series of nice 
small changes (commits) to the latest upstream reference point (often tip of 
master/production), and while doing the rebase, you fix all the conflicts (with 
the NWO changes) as you go to create a clean sequence, and then you will have a 
commit/patch series that can either be fast forward applied, or merged without 

    Obviously (?), having done your rebase you will have to style check, 
compile and test you new magic code to see if it actually works as planned 
without any regressions (and fix a few minor mistakes). By which time the NWO 
has moved on again, so another quick rebase gets you to the head of the queue, 
and you are awarded tea and medals.

    The other scenario is that you are working on say git itself and you send 
in patches for review, which end up with fixups and comments, so you have to 
continue to rebase your own work forward to the relevant start point, 
especially if there is an overlap with other patch series.

    The "problem" doesn't exist in other, non-distributed, systems because of 
the restrictive check-out - check-in process which nails both feet to the floor 
to stop you going round in circles (and limits progress!). Rebase lets you leap 
ahead and catch up with the latest and greatest code release, or a 
collaborators code, or wherever. 

Hi david,

Interesting question. The distinction is about 'who does what', and how is the 
hsitory to be presented. 

If it is just you on your own, then a rebase is likely to be rare. You would 
use it if you started a piece of work from the wrong start point and wanted to 
make that commit series start from the right point. Otherwise you can merge 
your way forward anyway you please.

In a multi-developer situation there are often rules and conventions that mean 
you have to 'keep up' with the work of others, so you have to sort out the 
conflicts *before* your commits are merged into the main workflow (with the 
merge having minimal conflicts), so you rebase your work, in your local repo, 
onto the tip of the fetched mainline (which had moved on), fixing the conflicts 
as the commmits are rebased, leaving you with a clean series that obviously can 
be either fast forwarded, or merged without conflict, into the main line.

Summary. In a rebase you fix conflicts before the merge, while in a regular 
merge you usually have conflicts to fixup afterwards (after the auto-merge 


You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to