[Python-Dev] PEP: Collecting information about git

[R. David Murray]

On Wed, 16 Sep 2015 19:59:28 +1000, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Sep 16, 2015 at 7:46 PM, Oleg Broytman <phd at phdru.name> wrote:
> > For example, I develop
> > SQLObject using two private clones (clean backup repo and dirty working
> > repo) and three public clones at Gitlab, GutHub and SourceForge. They
> > are all equal, none of them is the upstream. I don't even have
> > ``origin`` remote - the origin was in Subversion.
> 
> Right. And even when you do have an 'origin' remote, you can pull from
> anywhere else. (Internet connection's down? Pull from one computer
> straight to another over the LAN. Want to quickly compare two messy
> branches, without letting anyone else see them yet? Pull one of them
> onto the other computer and poke around with fred/master and master.
> Etcetera.) Deployment on Heroku can be done by setting up a remote and
> then "git push heroku master". Does that make those commits
> uneditable, or does "git push origin master" do that? I like the way
> git lets you shoot yourself in the foot if you want to, while warning
> you "your gun is currently pointing near your foot, please use --force
> or --force-with-lease to pull the trigger".
> 
> But this is a bit off-topic for python-dev.

Yes is it, and no it isn't, if we are even thinking of moving to git.

My experience with DVCS started with bazaar, moved on to hg for the
CPython project, and finally git.  Through all of that I did not
understand the DAG, and had trouble wrapping my mind around what was
going on, despite being able to get things done.  I read a bunch of
documentation about all three systems, but it wasn't until I watched
another instructor teach the git DAG at a Software Carpentry workshop
that it all clicked.  Partially, I had been continually confused by the
concept of a "branch", since git uses that term differently than CVS,
svn, hg, or bazaar.  But once I understood it, suddenly everything
became clear.

The DAG plus git branches-as-labels *fits in my head* in a way that the
DAG plus named-branches-and-other-things does not.

I think that's really the key thing.  Sure, you can do the equivalent in
hg, but hg is not *oriented* toward that simple model.  git has a simple
model that my mind can wrap around and I can *reason about* easily.
Figuring out how feature branches and throwaway branches and remote
branches and pushes and pulls and workflows and whatever is all all just a
matter of reasoning about this simple model[*].

*That* I think is the key to git's success, *despite* its command line
API woes.  Not github, though github has magnified the effect.

The other key concept is what Chris talks about above, Mercurial's
"prevent me from shooting myself in the foot" stance versus git's "shoot
if you really want to" stance.

I think Mercurial is a great product, and has lots of really great
features, and I suspect that phases is a power tool that will enable
certain workflows that git won't support as well if at all.

But, I think Mercurial matches what we might call the "corporate"
mindset (prevent me from shooting myself in the foot) better than the
Python mindset.

Python strives to have a simple mental model you can reason about, and
it is a consenting adults language.  IMO, git matches the Python mindset
better than Mercurial does.

Now, does that mean that *the CPython project* should adopt git?  Not
necessarily.  CPython may be more like a big corporate project, where
centralized tracking of the main lines of development and not shooting
ourselves in the foot are the most important things :)

--David

[*] And then getting confused about how to *do* it in the CLI, but hey,
Google is my friend.