Workflows, rebase, patch theory

[Stephen J. Turnbull]

Vincent Ladeuil writes:

 > 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.

+1

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

... which is utterly vague once you think a bit more about it.
Commit-per-keystroke, anyone? :-)

 > 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.

+1

 > 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:

 > - anything you can think of.

Well, all of the things you mentioned, both in this paragraph and
above, seemed to have two properties: a linear "true" history of a
branch, at least, and those commits are filtered according to some
criterion.

I don't think you are really thinking that way, so your examples are
somewhat limiting.  In any case the reality here is relativistic.
There is no linear history.  For example, IIUC the development history
(where actual calendar time is on the horizontal axis)

  ,---B      upper fork
 /     \
0       C    "mainline"
 \     /
  A---'      lower fork

would be bzr logged differently after synchronization:

    my repo                    your repo

    2       merge              2       merge
      2.1   feature B            2.1   fix A
    1       fix A              1       feature B
    0       ancient history    0       ancient history

depending on where bzr log is invoked.  I think this is the correct
UI; from your point of view A happened "later" in your repo and
experience than "B", even though in time I coded and committed it
first.

There's also another important POV that the current tools (except
Darcs) *cannot* handle in general, which is preordering by patch
dependencies.  (However, something very useful that is similar is
ordering/filtering on patches that touch a group of files.)