[Libre-soc-dev] git.libre-soc.org mesa repo branch

[Hendrik Boom]

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".

I see.

> 
> > > 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
> ignored.

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 
developer interaction.

> 
> 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. 

-- hendrik