On 2016-08-25, at 2:44 PM, Philip Oakley <philipoak...@iee.org> wrote:
> 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
> • 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
> 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
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
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
For more options, visit https://groups.google.com/d/optout.