Jan Hudec <bulb@xxxxxx> wrote: [...] > Reading this thread I came to think, that the revnos should be assigned > to _all_ revisions _available_, in order of when they entered the > repository (there are some possible variations I will mention below) > > - Such revnos would be purely local, but: > - Current revnos are not guaranteed to be the same in different > branches either. > - They could be done so that mirror has the same revnos as the > master. Then they are almost useless (except for people working alone). You need to be able to talk about a particular commit with others working independently. > - They would be easier to use than the dotted ones. What (at least as > far as I understand) makes revnos easier to use than revids is, that > you can remember few of them for short time while composing some > operation. Ie. look up 2 or 3 revisions in the log and than do some > command on them. And a 4 to 5-digit number like 10532 is easier to > remember than something like 3250.2.45.86. Probably. In git you can (mostly) get away with partial SHA-1's, BTW. > - Their ordering would be an (arbitrary) superset of the partial > ordering by descendance, ie. if revision A is ancestor of B, it would > always have lower revno. > - The intuition that lower revno means older revision would be always > valid for related revisions and approximately valid for unrelated > ones. > - They would be *localy stable*. That is once assigned the revno would > always mean the same revision in given branch (as determined by > location, not tip). Tip-relative is extremely useful: I wouldn't normally remember the current revision, but I'll probably often be talking about "the change before this one" and so on. > - This is more than the current scheme can give, since now pull can > renumber revisions. Urgh. Get an update, and all your bearings change? > - They wouldn't make any branch special, so the objections Linus raised > does not apply. But the original branch /is/ special? > - They would be the same as subversion and svk, and IIRC mercurial as > well, use, so: > - They would already be familiar to users comming from those systems. > - They are known to be useful that way. In fact for svk it's the only > way to refer to revisions and seem to work satisfactorily (though > note that svk is not really suitable to ad-hoc topologies). SVN is /centralized/, there it does make sense talking about (the one and only) history. In a distributed system, potentially each has a different history, and they are intertwined. Not at all useful. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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