On 2016-08-25, at 2:44 PM, Philip Oakley <philipoak...@iee.org> wrote:

> Hi,
> I think you should review points 1 and 2 because they try to re-inforce a 
> centralised control system. And then pass off the responsibility to a machine.

Actually, I think that those points are still relevant even today:

> What is important:
>       • pull requests: would like to kick off build based on approval of code 
> review
>       • branch permissions: we want to disable direct commit to master 
> branch. we do not want devA to be able to modify branch created by devB (not 
> a deal breaker if unavailable)

The idea that one developer is responsible for the code on a given branch is 
not a bad thing; actually making someone responsible for changes to a setup, 
with the ability to say "approved" or "not approved" is a good thing.

It's perfectly OK for devA to make a suggested change -- a pull request -- to 
devB's branch, but devB is the one that says "yea" or "nea". If DevA still 
wants it done, then devA makes and owns their own branch.

There is no "Not my fault" in this approach.

Equally, the first goal of requiring code reviews and pull requests is also a 
good thing.

> Given that Gitb is a "distributed control" system, 

Git can be a distributed system. It has all the elements needed. It does not 
enforce a top-level master.

But it can still be used as a top-level master.

Most SCM's are based on "One repository serves many developers". Git is based 
on "One repository serves one developer, and the repositories can share with 
each other".

But there is one Linus at the top of Linux.
In any public/open coding project, there is one person that decides to compile 
and release the code in project X, even if there are other people that forked X 
and want to release their own version. 

Someone has to say "This is good"; someone has to put their name on it. Someone 
owns the repository that is considered the "master" by the people who are going 
to release and support the program used by others.

> It's much better if responsibility stays with the human (see the `git help 
> workflows` man page, `tutorials` page, user-manual and especially 
> https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows).

Yea, I've looked at those. They fail to adequately describe what I would have 
thought was a very common behavior / my normal use case -- making a fork of an 
existing project, making my changes on a branch off the old master, and then 
submitting that branch as a pull request to the master. In the process of 
trying to understand this, I found that "pull requests" are actually something 
added by GitHub and BitBucket, and are apparently not a git-native feature.

There also isn't a really good description of what to do when someone else 
forks your code, makes changes on master, and then submits a pull request from 
their master to your master -- which is as close to a "no-no" as I can imagine, 
I want their stuff to come in on a branch.

I remember a really good article pointing out that the "trivial" setup of every 
developer pulling directly from each other's branches and making changes -- 
something that is apparently a chapter 1 or 2 concept in all git books -- is a 
horrible setup that does not scale and causes all sorts of issues. (That does 
not mean I could explain the problems/issues, just that I learned not to do 
that). So, the lack of a good "Here's how to actually set up a real-world, 
multiple-devs contributing to a given codebase that has a central "sign-off" 
person -- even not even considering that there is a central person because 
"Distributed for the win!", just results in lots of people trying to re-invent 
the wheel with no actual learning/progress.

Git is assembly language; we are currently at a mix of fortran/cobol/basic in 
it's usage. I'm not sure that people even know what is the "goto" to avoid yet; 
it's certainly not clear to me. Heck, there's how many different versions of 

Entertaining minecraft videos

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to