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.
