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
For more options, visit https://groups.google.com/groups/opt_out.