[Mono-dev] The new world of Git -- what else can we change :-)

[Jon Frisby]

On Jul 28, 2010, at 11:21 PM, Avery Pennarun wrote:

> On Thu, Jul 29, 2010 at 12:03 AM, Jon Frisby <jfrisby at mrjoy.com> wrote:
>> This isn't QUITE accurate.  Tags are intentionally harder to change precisely because they are intended to have a
>> degree of 'permanence' and be outside of the day-to-day workflow that branches are for.
> 
> Right, but I don't think anyone is talking about changing these tags,

I didn't mean to suggest that anyone was talking about that, I'm pointing to the difference in semantics between tags and branches to illustrate the difference in intended use-case.

> really.  (And you can still update them, it's just a manual process.)

Of course.  Git makes very few things 'impossible', it just encourages and discourages things for the most part.


>> To that end, they include another important feature that branches do not, which is the ability to sign the tag
>> when it's created, which gives you some assurance that the tag is from who it claims to be from (making
>> trustworthy releases possible in a DVCS environment).
> 
> Yeah, in that case there's a little bit of GPG sugary wrapping on top
> of the tag file.  But it's still nothing much more than a branch with
> a GPG signature.
> 
> It still points at a particular commit id (sha1 hash).  It's just that
> the pointer is GPG signed.

And there's the addition of a comment, which branches don't have -- although that's not an argument in favor of anything.  Just a detail for the sake of completeness.

To expand on your logic a bit -- branches are nothing more than sugary wrapping on top of pointers.


>> So yes -- generally speaking all releases 'should' be tagged if you want to keep things git-ish.
> 
> That's optional of course; if you didn't need GPG before, you don't
> suddenly need it now.  It is certainly the git way to do it, though.

Most things are option in Git, by design.  Like Unix it adheres to a model of 'separation of mechanism from policy'.  Tags and branches are two (very light-weight) mechanisms it provides.  The question of *policy* is entirely at the discretion of the user.  And thus we get to have fun debating what policy is likely to produce the least aggravation and greatest productivity for the greatest number of participants. :)

I'm merely suggesting that the mechanism of tags seems to be a better fit for the use-case of recording release histories (and, in fact, it was designed with that in mind) and that the fluidity of branches makes them somewhat less desirable for that use-case.  The question of whether or not to actually USE the GPG signing feature is a separate one that I have no opinion on.

The particular policy/workflow that seems most intuitive to me would be to branch from master or wherever in preparation for a release, make whatever tweaks/adjustments are needed in order to finalize it (I.E. any hacks to build scripts or whatever) on that branch, and when you reach a commit that is capable of building all the desired builds for the release, tag it as that release, shove the build tarballs out to wherever, merge anything relevant back into master, remove the branch, and move on.


>> As for the question of branches, I've become fond of the idea of using an
>> ad-hoc hierarchy of names starting with the name of the branch's 'owner'
>> and with other namespaces for branches that are considered shared/important.
>>  So I might have jfrisby/MonoTouch/MyTopicBranch, and whether or not I push
>> it up to github.com/mono/mono.git is a function of how much value I perceive
>> there to be in sharing it in that manner -- although I would almost certainly push
>> it to github.com/jfrisby/mono.git regardless.
> 
> Hmm, if it's only a branch that you're working on - which is implied
> by the jfrisby/ prefix - then I don't see any reason to put it in the
> shared repo.  That's exactly why github has a jfrisby/mono repo.
> 
> If you expect *other* people to be pushing to jfrisby/* branches,
> well, that's just crazy and perhaps you shouldn't be naming them with
> your username like that :)

You have a good point there...

I had envisioned a scenario wherein an individual is doing something 'important' as a project -- important enough to beg collaboration, but transient enough to not qualify for any sort of 'official' status yet.

Of course the collaboration could happen entirely via github.com/jfrisby/mono.git too so perhaps this is just some SVN-induced brain-rot seeping through in my ideas. :)

-JF