On 2009.04.24 15:08:05 +0200, Jakub Narebski wrote: > On Mon, 20 April 2009, Björn Steinbrink wrote: > > On 2009.04.20 11:59:38 -0700, Jakub Narebski wrote: > > > Björn Steinbrink <B.Steinbrink@xxxxxx> writes: > > > > > > > If you go out, and look at a tree lit-up by the evil daystar, branches > > > > start at the trunk and end at their tip. The trunk isn't part of the > > > > branch. [...] > > > > > > Well, you have to remember that the 'branch' metaphor should not be > > > taken too literaly; take for example merges which do not have > > > equivalent in a tree build. > > > > True, but that just happened to fit the task-oriented branch view so > > well, and I wanted the reference to the evil daystar (obviously ;-)). > > Also in (botanical) trees you can usually distinguish between trunk > and side branches, and I think in most cases also which branch forked > from which one. Making one of branches (trunk) special might make > sense for centralized version control systems like CVS (1.2 vs 1.2.2.4 > version numbers) or Subversion (<project>/trunk for trunk (main branch) > vs <project>/branches/<branchname>; although this is only convention > and is not enforced by the tool), but in my opinion contradicts > distributed nature of distributed SCM such like Git (and Mercurial). > > > > But if we are talking about literal branches: take a closer loog at > > > the tip of tree (plant) branch. You can find growong tip there > > > (apical meristem) where new cells grow. In Git you have 'branches' > > > (branch heads) where you create new commits... > > > > Yeah, see the end of my mail, where I said that git has a mechanism to > > control where branches grow. Seems to fit :-) > > The difference is that you can (usually) see which branch was first. > It is not the case for Git (and it wouldn't make sense, as for DSCM > there is no sense of 'first' wrt. time). Hm, I'd say we're agreeing, right? What you said basically proves my point. You don't have "direct" access to the "branches" (the already grown parts, where you can tell where they start, end and originate from), but just to the branch heads/tip (where branches grow). I'm just saying that we might have to accept that fact and make it clear in the documentation. Not that we should make git support "branches" as first class entities. Even for "simple" things like repeated merges the analogy to branches in plants make little sense (as you said). > > > But I agree that there isn't for example true notion of 'trunk' in > > > git, and this is what allows Git to be truly distributed... > > > > Hm, not just no trunk, but also no branches that have a starting point > > and an end point. In general, you can't say "My branch starts _here_" > > unless you use the root commit(s) as the starting point, or you apply > > "extra" knowledge (you know from which other branch this branch forked). > > Well, you can use reflog... if it is not expired. Or the tracking info > in a config. None of that is available in a cloned repo where you might want to look at the history some "branches", wondering which commits form them, in a task oriented fashion. Björn -- 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