* David Golden <x...@xdg.me> [2015-05-19 19:26]:
> I've created "devel" branches for several of the dists I maintain. I'd
> like to leave "master" for things that ship, so that, for example,
> I can ship a stable release after a trial by shipping master.
I tried this in several projects, esp. including at $work, and eventually
abandoned the approach, for basically all the reasons that Kent listed.
> Other development work can go live on devel (or topic branches) while
> we wait for TRIAL releases to stabilize. I think this will be a good
> practice for the PTG in general. Thoughts?
At $work I ended up going the other way: a `master`/`release` combo.
For my smaller projects, I ended up not even having another branch next
to master. For releases I just tag commits on master. I think that is
adequate for projects with only a single committer who pushes to master.
Multi-committer projects do need some way of keeping people off each
others’ toes so they should probably have a workflow of all development
going into branches and landing in an integration branch. That would be
master.
Projects that actually require a RC phase with potential for significant
stabilisation work would need a branch for that, which probably ought to
be something other than master, e.g. “release”. (Just cutting a TRIAL as
a precaution isn’t the same to me, though.)
Mind you, that is the absolute minimum best-practice branch/tag workflow
I think should be suggested; if you want to formalise extra branches for
keeping track of your TRIALs etc, that’s obviously fine.
* Kent Fredric <kentfred...@gmail.com> [2015-05-19 22:50]:
> That is, I think semantically, "master" and "blead" are similar, and
> assuming "master" to mean "stable" is a bit odd.
Yeah, I’ve settled into that too.
> Though my thinking is obviously at odds with a lot of peoples here,
> its based on the idea that "master" is universally "the default
> branch" in Git. The default branch for commits and pushes and etc etc
> etc.
There is variety of places where Git assumes master is where development
happens, such that I always felt friction when I tried to work against
that. Off the top of my head, the default merge commit message comes to
mind, which will explicitly say
Merge branch 'topic' into 'devel'
for any target branch other than `master`, where it’s a plain
Merge branch 'topic'
That’s hardcoded.
I encountered various corners that grant primacy to the `master` branch
in this way. At some point I realised I was fighting Git on this matter,
and that this was a waste of effort, so I stopped.
> Having to tell everyone using some mechanism that "the default" is not
> the regular default is just peculiar.
FWIW, in my clone of perl5.git I deleted `blead` and created a `master`
branch whose upstream is set to `origin/blead` – that’s how tired I had
gotten of the friction. (So far the illusion appears perfect so I guess
Git only specially cares about the local `master` branch.)
If we were doing the Perforce migration now, I would advocate against
retaining the old nomenclature – despite the need to rewrite docs and
some of the tooling (which would be needing adjustment for Git anyhow).
Even with the migration being long past, I still contemplate advocating
a switch to `master` every now and then.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
