On Mon, 23 Oct 2006, Matthew D. Fuller wrote:
But I don't understand how bzr-the-abstract-data-model makes such
things impossible, or even significantly different than doing so in
git. In git, you're just chopping off one DAG where another one
intersects it (or similar operations). To do it in bzr, you'd do...
exactly the same thing. The revnos, or the mainline, are completely
useless in such an operation of course, but they don't hurt it; the
tool would just just ignore them like it does the SHA-1 of files in
the revision.
one key difference is that with bzr you have to do this chopping by creating the
branches at the time changes are done, with git you do this chopping after the
fact when you are displaying the results.
As such you can chop and compare things in ways that were never contemplated by
anyone at the time changes are made.
See? When you visualize multiple branches together, HAVING
PER-BRANCH REVISION NUMBERS IS INSANE! Yet, clearly, it's a valid
and interesting operation to do.
I wouldn't be so absolutist about it, but certainly they're of
extremely limited utility if of any at all in such cases. And yes, it
can be an interesting operation. But what does that have to do with
using revnos in other cases? You keep saying "having" where I would
say "using".
and the bzr tools strongly encourage the use of these numbers
I care about that first parent line. Therefore, I require my tool to
at least _pretend_ to care. I'm not aware of any way in which the
fundamental bzr structures care, but the UI is chock full of
pretending. A necessary part of that pretending is not changing my
mainline unless I specifically ask for it, and that means a
merge-vs-pull distinction needs to be there. That's a _technical_
sign that the tool is ready to work with me the way I want to work. A
lack of it is a _technical_ sign that it's not suitable.
nobody is saying that the bzr approach is invalid for your workflow.
what people are saying is that it doesn't easily support a truely distributed
workflow. this is a very different statement.
your workflow isn't truely distributed so you bzr's model works well for you. no
problem, just don't claim that becouse you haven't run into any problems with
your workflow that there are no problems with bzr with other workflows.
David Lang
-
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