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 why?

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?

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 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to