Workflows, rebase, patch theory

[Talden]

>  > > I don't see how "information about what happened when" is "noise",
>  > > especially in a system that's designed to preserve exactly that
>  > > information — which is what a VCS is designed to do.
>  >
>  > If you have to review a patch serie, you don't care about the
>  > mistakes fixed later in the serie, you don't care about when the
>  > author of the patch merged from upstream, ...
>
>  This is an argument for allowing the user to filter what they see,
>  *not* for throwing away information from a branch history.
>
>
>  > There is a _huge_ difference between the published history, shared
>  > by everybody, and your own private space. The history you publish is
>  > a description of the logic between the starting point, and the end
>  > point. Your private history can contain your mistakes and mess, but
>  > you're the only one who may need it.
>
>  I think that's been demonstrated untrue elsewhere in this thread. If
>  you're not convinced, I won't try again in this message.

I don't think it's been 'demonstrated' at all.  The preference has
been expressed.  But aren't we pro-choice here?  The capability to
squish history before it's released for consumption is a useful
feature.  The alternative is pushing local changes to a patch queue,
pulling in from upstream and doing no branch commits until it's
final... Then you've got the ultimate extreme of throwing away
information as it's the equivalent of squishing all of the branch
commits in addition to rebasing the branch.

I think it has been demonstrated how many upstream merges can degrade
the visibility of useful information in the log - I have yet to hear
an argument that explains how knowing the timeline of these upstream
merges is useful. It doesn't tell you anything about the development
of the branch changes, it only tells you how often the developer felt
the desire to 'sync-up' with their parent branch.

Note that there may not have been a need to sync-up how can the branch
developer know until they see the changes - so those merges don't even
give a hint as to why the merge was done other than the developer saw
upstream changes and incorporated them.

--
Talden