Workflows, rebase, patch theory

[Ben Finney]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> Ben Finney writes:
> 
>  > > The big disadvantage is you're throwing away history
>  > 
>  > Yes.
> 
> I don't understand why people keep saying this when it quite
> obviously isn't true. The only time git ever throws away history is
> when you run "git-gc --prune". What happens in git-rebase is like
> ripping a page from the index of a history book while leaving the
> descriptive text intact, not like ripping out a chapter. Oh, and I
> guess you then scribble a new summary of the chapter on the flyleaf
> so you can find it easily.

My understanding is this: The state of the tree to which a revision
was applied is a fact of history that gets "thrown away" by rebase.

Is that wrong?

> So what *is* true is that the link between a branch name and a
> certain history is broken by rebasing.

By "a certain history" I think you mean what I called "the state of
the tree", including the current set of revisions. The fact that a
revision was applied in the context of a particular state of the
branch is information that is part of the history of the branch.

> This is a genuine, important problem, but if you identify it as
> "throwing away history" then you probably are eliminating a large
> fraction of the possible ways to solve it.

I hope the above makes it clear why we're considering it so.