Workflows, rebase, patch theory

[Vincent Ladeuil]

>>>>> "Ben" == Ben Finney <bignose+hates-spam at benfinney.id.au> writes:

    Ben> Matthieu Moy <Matthieu.Moy at imag.fr> writes:
    >> Ben Finney <bignose+hates-spam at benfinney.id.au> writes:
    >> 
    >> > 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, ...

    Ben> This is an argument for allowing the user to filter what they see,
    Ben> *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.

    Ben> I think that's been demonstrated untrue

Sugh a gift... Thanks a lot for that. 

I disagree.

untrue is far to definitive. It may be true, today, that it is
not possible for me to have a richer history than the trunk, but
*that* could be changed.

One thing that is clear for me from this discussion is that:
there is several ways to present the history of a project and
different people have expressed different needs.

One point of view is that the full history of a branch should be
shared without restrictions, including errors and mess.

Another one is that the history of the project should be as clean
as possible (which is utterly vague once you think a bit more
about it).

I don't think these two points of view have to be exclusive.

What I'd like is being able to enrich the history of a project
by showing different parallel ways to reach a new feature in
terms of code modification. Such history representations could
include:

- only revisions passing tests,

- only clean revisions showing, say, how to implement the feature
  by testing first,

- the exhaustive history showing that, well, you got
  understanding by writing the code and, yes, you're not perfect,
  there are dead ends (some really stupid, but some others so
  enlightening or worth sharing in the memory of the project to
  point people at when some subjects come back),

- anything you can think of.

I think all the tools are available today to handle that*, the UI
may need tweaking, the data model may need some small
adjustments if we want to allow, say, publishing (and sharing)
only some histories, but nothing fundamentally impossible.

     Vincent

*: As long as you end up with the same code in two branches, you
 can merge them creating an alternative history.