On 03/29/2009 07:32 PM, John Bowler wrote:
> I'm reading quite a lot into this, my apologies if I'm making false
> assumptions. I think I understand the basic idea and I think the underlying
> intent can be fulfilled by GIT, but I may be wrong. Here's what I
I won't go so far as to say "false" assumptions, but I think there
are a lot of unnecessary assumptions in what follows, as detailed
> 1) The top level names (master, stable, devel, legacy) *replace* the current
> branches v00, v10, v12 and v14. (I misunderstood this at first - I made the
> same assumption of a hierarchy as Brandon made - it's obvious when you know
> what it means.)
I see two types of names here:
a) There are conventional meanings for the words "stable", "devel",
and "legacy". I assume there is no intent to change the meanings
of these words.
b) Also there are conventional meanings associated with version numbers
such as v00, v10, v12, and v14.
Alas there is not a clean mapping between type-(a) names and type-(b)
names. Common experience in software development says that yesterday's
"devel" branch may be tomorrow's "legacy" branch.
> 2) master, devel and legacy are simply the result of:
> git branch -f master v12
> git branch -f devel v14
> git branch -f legacy v1.0.12
That might be OK for today but would have to change in the future,
and we don't want a policy that would make such changes painful.
> Since there are currently only two active tips (v12 and v14) in the GIT
> repository the presence of "master" and "devel" satisfies the subtle GIT
> requirement that a repository has a branch name for each active tip (==
> childless revision).
I don't think there is any such requirement. There is the totally
non-subtle requirement that branches have names. Therefore the
active tip is the HEAD of some branch. The HEAD is childless unless
you've been playing games with git-reset. The presence of "master"
and/or "devel" is not needed to satisfy any git requirement, subtle
> The requirement arises because otherwise git clone and
> pull won't retrieve the revisions leading to the tip (I think.)
In my experience, when they are told to retrieve X, they also
retrieve everything leading up to X. They pretty much have to,
given that everything is stored as a delta.
> v1.0.12 has a child revision, but "legacy" may become childless in the
> future if something causes 1.0 to be patched. v00 doesn't need to exist
> because v0.99m won't ever be patched and v1.0.0 is its child.
I don't understand what that is saying. I suspect it deals with
questions that do not need to be asked, let alone answered.
> 3) "stable" is the difficult one. Glenn seems to think of it as a branch
> with only the public releases on it, so it would currently be v1.2.35 and
> stable~1 would be v1.2.34 and so on through v1.2.0 then, before that v1.0.11
I don't see any difficulties with having a "stable" branch. Git
excels at supporting this sort of thing. There can be any number
of "playpen" branches, private and/or public. When a patch has
been thoroughly tested, it can be moved from the playpen branch
to the stable branch. The move can be carried out by git-cherry-pick
or by various other means. After the cherry-pick it is helpful
and traditional to do a git-rebase on any playpen branches that
stem from the stable branch.
When it comes time for a new release, that's just a tag on the stable
> I think this is all pretty straightforward, obvious and consistent with GIT
> apart from "stable".
I don't see anything even slightly challenging about having a "stable"
> I also think "stable" is useful - the intent is to log
> the latest release. Sure, this could be done by a note on a web page, but
> why disassociate the information from the place it is used?
That's what git-tag is for.
> I think the need can be met by:
> git branch -f v1.2.35 stable
Try git-tag instead.
Respect the difference between branch-names and revision-names.
There are generally many revisions on a branch.
> Then repeat this on every release. True, the history isn't there - I said
> how that might be done, but GIT doesn't really support it.
Git supports doing everything that needs to be done (including immutable
history) for for this project ... and for projects of much greater size