rlaager at wiktel.com
Wed Jul 9 22:38:15 EDT 2008
On Wed, 2008-07-09 at 20:39 -0500, Gary Kramlich wrote:
> I sent a couple of patches, and I received some comments, so I was
> > expected to modify the patches, isn't that mutating the history?
> > Imagine the patches where in my mtn repository, and somehow I'm able
> > to fix them, and send them again. The maintainers shouldn't care about
> > how the patches where created, just that they are ok.
> If the patch was provided as a pull from your database that you served
> via mtn serve for us to grab the revs
Here's how I imagine this working (using Felipe as a hypothetical new
contributor and me as the hypothetical developer reviewing his code):
1. Felipe says, "I hate that Pidgin does/doesn't do X. I'm going to
fix that. He checks out Pidgin. (Ideally a shallow checkout
should be an option.)
2. Felipe writes some rockin' code, committing to a branch he
created for the purpose as he goes. This is `vcs commit -b
new_branch` initially and `vcs commit` later.
3. He pushes his branch to somewhere like Launchpad, for example.
Please don't hate on me if you don't like Launchpad in
particular, it's just an example. Launchpad sends an e-mail to
people interested in such things (individually subscribed or by
team or a mailing list or whatever). I'm one of those people. I
click a link to view the diff. (Ideally, it would be against
trunk if it merged cleanly, otherwise against the last revision
that it merged cleanly against. Super-ideally, it would have
done a test compile and I wouldn't have to see it if it didn't
compile and pass make check, but we're not there yet.)
4. I like the code, but suggest a few changes (via the web
interface or e-mail or whatever). This communication is logged
with the branch, sent to Felipe, and it's marked pending or
whatever so we know it's been reviewed.
5. Felipe sees my comments and addresses them with code changes. He
makes more commits and when he's ready, he pushes again.
6. I get a new notification. I like the changes. I merge the branch
Now, you'll notice in this work-flow that I only reviewed diffs from
trunk at certain states. This is what happened in the past, where people
would use cvs diff and mail in a patch. This is in effect what is
happening with a git-rebase and a diff. In Monotone, you'd have a
propagate and a diff. (For our hypothetical code review service like
Launchpad, it could be doing an explicit_merge bisect if the patch
didn't apply cleanly.) Anyway, it's all the same effect from a review
stand-point, and this is what Linus (and every reviewer) wants (make
other people to clean it up as much as possible).
However, with a non-mutable history, I can see all the steps in the
middle, if I want to see how the code developed. If I don't care, I just
don't look at that.
Now, once it's merged, if you're looking at branches on trunk, you see
the merge, which should have a changelog of something like: "Merge in
code from Felipe to do X." The diff from that revision against its
parent on trunk is the clean net diff that you'd get from the
traditional diff & mail process or from git-rebase. However, all the
real history is there as well, if you care to follow the tree up the
Monotone lacks the hosting service and the shallow checkouts. git and
bzr, from what I read, have those (though Launchpad is closer to this
idea than a generic git host), but they lack a native way to represent
things like the test case passing, but I'm not sure that matters
(because the hosting service could store that separately anyway).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Devel