On 2008-02-06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > Note that rebase (and I would guess "transplant" -- why do the > Mercurial people insist on breaking the common idiom so often?) are
Heh, I think that DVCSs are new enough that *all* of them have broken the common idiom regularly. > I'm not sure what you're saying next. A slight gloss makes clear what > I think it is: > > > So if we [try to] model this workflow on a DVCS like Mercurial or > > Git [without transplant/rebase], here's what we wind up with. [...] > > You have a complete history, but not a final, complete patch of > > each logical feature. That model doesn't work [in the Linux kernel > > workflow]. > > Is that OK? Yes. > Well put. But you forget that "presumably" later. > > > Now, this model works well for private repos. In both git and hg, it > > is difficult to use -- though not impossible -- if you are sharing > > repos with others. > > Actually, it's not difficult at all (in principle!) It just requires > a bit of discipline about which branches you expose and how. Much of > this discipline can be automated (I haven't done so yet, though I > suspect that many lkml denizens have; cf. comments about reflog, > below). That has me confused, and pardon my butchering of git jargon; I'll use Mercurial here because I grok it... So my understanding of how rebase works is that you take all the patches since the last upstream release from one branch and apply them on the other branch. People that are tracking your repo will be following branch A (let's call that your original local branch). Now you have created branch B with your rebase, and never will merge. In Hg lingo, you now have two heads. So what will Joe Random Developer do now? He will somehow have to switch from your branch A to your branch B. This will not be automated, because how is his VCS to know what branch becomes your new canonical one? What's worse, the only common ancestor is the very first upstream version pulled in. > > That seems similar to using amend-record in darcs. > > Maybe. But amend-record actually destroys history, whereas the only > command in git and Mercurial combined that does so is git-gc. That is a fair point; I used "throw away history" too loosely. Git and Mercurial users will tend to ignore it in the rebase/transplant scenario, but yes, it still exists -- though in a not terribly convenient form, after a rebase. > it's not clear to me from following darcs-devel with its two-line > patches followed by 2000 lines of dependencies that in practice the > notion of dependency actually used isn't pragmatically equivalent to > ancestry.) I have never really grokked how Darcs dependencies are calculated. But I have suspected this myself at times. > > features, it does not have a way to arbitrarily merge two patches > > back in the history -- at least not a convenient way. > > Worse yet, Darcs is ahistoric. That's what it means to say that there > is no complete ancestry DAG. > > But I don't understand what you're asking for here. Specifically, > what's missing from "patch < PATCH-A && patch < PATCH-B && darcs > record"? Well, first you'd have to darcs diff -u to get the two patches, then commit a patch undoing them, then this one, and you still have the "ugliness" in your history. > > * Loss of development history due to having to throw out old branches > > This is a common misconception about how rebase works. No history is What about the commands that let you combine two separate git patches into one? -- John _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
