Re: What's cooking in git/spearce.git (topics)

[Daniel Barkalow <barkalow@iabervon.org>]

I keep thinking that there should be a better mechanism to use for "pu" 
than a branch. Normally what you see in "pu" is a sequential merge of 
"next" and a number of topic branches, where the series of merges is 
either entirely uninteresting or only interesting in a schematic sense 
(that is, it is interesting what topics appear, and in what order, but the 
snapshot of each topic's head when it got merged isn't interesting).

That is, the work which "pu" consists of, and therefore the history is a 
sequence of steps, each of which is one or more of: "add this topic", 
"update this topic", "remove this topic", "update to a new next". And we 
don't keep a record of this history, but it's not what's discarded by 
rewinding anyway.

I think that, if we actually care about this sort of thing, we'd want to 
make "pu" a series of commits, each with the previous "pu" as the sole 
parent, with a series object given in a new header. The series object 
would start with a "next" commit, and then list the topics merged by name 
and head-as-merged. Of course, the "pu" commits would contain the 
resulting tree as normal, so that people without a git that understands 
this would see "pu" as consisting of a straight line of commits, each of 
which simply shows the net effect of the changes. Or something like that. 
I suppose "pu" could also be represented as a superproject where each 
subproject is "next" or a topic branch, if we really want to avoid 
introducing new objects, but that seems unweildy somehow.

Is this worth doing? It might be; I bet it would make debugging -mm a 
whole lot nicer. (First bisect through -mm to find the action Andrew took 
that accepted the breakage, then bisect the history within that action.) I 
bet the status quo is a real pain when the feature that broke is only in 
-mm and later in Andrew's list than the tree whose change triggered the 
failure (i.e., -mm4 works; -mm5 doesn't work, and everything in -mm5 is 
either broken or untestable).

And, of course, "origin/pu[db/builtin-fetch]" would be an easy thing to 
build into git, and it could even generate extra magic, where it knows 
what the topic was last rebased on, so git could lead people through 
"rebase everything in a pu collection on the new base for the collection"
and "make my local topic branch agree with my topic branch as present in 
origin/pu".

	-Daniel
*This .sig left intentionally blank*