> This is why changesets need to be first-class objects in the repository,
Right.
> that can be versioned,
Versioned how? Have different versions of a changeset? Don't see the point.
> segmented
Here I disagree. The changeset should be seen as a (conceptually atomic)
change to the _local_ repository. The "conceptually atomic" part is from
Linus' style of "break up your megapatch into self-contained pieces, do one
step at a time". The changeset must make local sense if you want to be able
to undo, see what it changes, handle dependencies, ... Locally, what was
changed remotely (generating the changeset in the first place) is useless
(as the context isn't here).
> and recombined.
Recombined how? Take changesets A and B, create C from half of each? Better
keep A, B, and create another one that gets rid of the junk. Or do a C from
scratch (perhaps by applying A and B as patches, fixing up the mess, and
declaring the resulting change a changeset).
It does make sense to group changesets, but not this way AFAICS.
> I'd be able to pull
> slightly differing changesets from a variety of sources, *merge
> the changesets* and carry the result forward in my repository. This
> way, no changeset needs to lose its identity until I explicity want it
> to.
This is doing merging among changesets, not merging changesets into the
repository. I'd prefer the later (as it reduces this special-purpose
operation to others that have to be there anyway).
-- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/