Aaron Bentley wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
Well, <ref>~<n> means <n>-th _parent_ of a given ref, which for branches
(which constantly change) is a moving target.
Ah. Bazaar uses negative numbers to refer to <n>th parents, and
positive numbers to refer to the number of commits that have been made
since the branch was initialized.
What do you do once a branch has been thrown away, or has had 20 other
branches merged into it? Does the offset-number change for the revision
then, or do you track branch-points explicitly?
One cannot have universally valid revision numbers (even
only per branch) in distributed development. Subversion can do that only
because it is centralized SCM. Global numbering and distributed nature
doesn't mix... hence contents based sha1 as commit identifiers.
Sure. Our UI approach is that unique identifiers can usefully be
abstracted away with a combination of URL + number, in the vast majority
of cases.
But this doesn't matter much, because you can have really lightweight
tags in git (especially now with packed refs support). So you can have
the namespace you want.
The nice thing about revision numbers is that they're implicit-- no one
needs to take any action to update them, and so you can always use them.
I wonder if any SCM other than git has easy way to "rebase" a branch,
i.e. cut branch at branching point, and transplant it to the tip
of other branch. For example you work on 'xx/topic' topic branch,
and want to have changes in those branch but applied to current work,
not to the version some time ago when you have started working on
said feature.
If I understand correctly, in Bazaar, you'd just merge the current work
into 'xx/topic'.
merge != rebase though, although they are indeed similar. Let's take the
example of a 'master' branch and topic branch topicA. If you rebase
topicA onto 'master', development will appear to have been serial. If
you instead merge them, it will either register as a real merge or, if
the branch tip of 'master' is the branch start-point of topicA, it will
result in a "fast-forward" where 'master' is just updated to the
branch-tip of 'topicA'.
What your comparison matrick lacks for example is if given SCM
saves information about branching point and merges, so you can
get where two branches diverged, and when one branch was merged into
another.
I'm not sure what you mean about divergence. For example, Bazaar
records the complete ancestry of each branch, and determining the point
of divergence is as simple as finding the last common ancestor. But are
you considering only the initial divergence? Or if the branches merge
and then diverge again, would you consider that the point of divergence?
merge-point tracking is a prerequisite for Smart Merge, which does
appear on our matrix.
Plugins = API + detection ifrastructure + loading on demand.
Git has API, has a kind of detection ifrastructure (for commands and
merge strategies only), doesn't have loading on demand. You can
easily provide new commands (thanks to git wrapper) and new merge
strategies.
I'm not sure what you mean by API, unless you mean the commandline. If
that's what you mean, surely all unix commands are extensible in that
regard.
I'm fairly certain he's talking about the API in the sense it's being
talked about in every other application. Extensive work has been made to
libify a lot of the git code, which means that most git commands are
made up of less than 400 lines of C code, where roughly 80% of the code
is command-specific (i.e., argument parsing and presentation).
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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