Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > You're simply wrong. A ref isn't a name for a commit (the point of > having a ref is that it doesn't persist in naming the same commit). A > commit isn't a blob. If you start telling people complicated and wrong > things, they're surely going to be confused. > > Git maintains history as a directed graph, with each commit pointing > back at its history. Refs are the what holds the newest commits that > nothing else points back to. If directed graphs aren't in your users' > experience, you can put it this way: git maintains history like > knitting, where each new stitch holds on to one or more previous > stitches, and refs are the knitting needles that hold the ends where > you're working (except that knitting is a lot wider than software > development). gitk --all even provides the diagram you want to explain > it. Complicated and right things are not much less confusing... > SVN branches are incredible confusing because they fail to distinguish > the directory structure of the project's source tree from the > arrangement of available latest versions. That is because there _is_ no difference. You just store different versions in different places. What they are named is a convention, nothing more, nothing less. > And the version numbers for your branch increase when changes are made > to other branches. You are confusing "version numbers" which are assigned by humans with "revision numbers" which are just an administrational timeline for the whole repository. Really, Subversion is rather simple to understand. But it is not a DVCS. Moving a history from one repository to another is not really feasible unless you are doing straight mirroring. -- David Kastrup -- 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
