[Libre-soc-dev] git.libre-soc.org mesa repo branch
hendrik at topoi.pooq.com
Thu Sep 10 14:53:49 BST 2020
On Thu, Sep 10, 2020 at 12:57:00PM +0100, Luke Kenneth Casson Leighton wrote:
> On Thu, Sep 10, 2020 at 12:49 PM Hendrik Boom <hendrik at topoi.pooq.com> wrote:
> > The developers of monotone, another distributed revision control
> > system, recommend making a branch for every bug, and pushing it to
> > any central repositories early in the process, before it's even
> > debugged. That way anyone in the project can look at it and offer
> > reviews and advice. This does mean a lot of short-term named
> > branches, but a problem with a not-yet-tested fix wont shut
> > anyone else out of their work.
> i totally get it. it's basically the "github" way of working (github
> is based around "Pull Requests" which can only be done through
> branches. see below about that).
I've always thought the overhead in pull requests makes it all
excessively formal. And therefore slow.
> this works extremely well for products that are on an "incremental
> development cycle". where it falls down is where the product is on a
> "rapid development and prototyping cycle".
> > > to give you an example of why committing and pushing is so important: only
> > > last week i lost git commits not once but TWICE due to a faulty laptop PSU.
> > Feeling free to push early to a branch without fear of
> > interfering with others' work would make this less likely.
> i've done this before: it resulted not in review and collaboration but
> in total isolation and, ultimately, made months to literally years of
> work utterly pointless because the branch was completely and utterly
The kind of branches I was thinking of last of the order of days,
at most a week or so, never never months.
You make a change, someone reviews it, you fix it, you commit to the
main development branch.
Actually, though, you mae a change in a bugfix branch, you commit it,
you push it to any central repository there might be, someone reviews
it, and you merge into the main development branch and push it.
I guess monotone goes well with a slightly different style of
> the lesson that i learned is that it is better for people to stop
> seeing it as "fear of interference" and to instead view it as being a
> necessary and beneficial *need* for the team to communicate and
> ultimately learn to collaborate and work together.
I see. It's a different, and effective, way of living with different
tools but achieveng similar communication and collaboration.
More information about the Libre-soc-dev