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* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
