Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #101115 > unrolled thread

Re: We will be moving to GitHub

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: We will be moving to GitHub Chris Angelico <rosuav@gmail.com> - 2016-01-02 07:09 +1100
    Re: We will be moving to GitHub Steven D'Aprano <steve@pearwood.info> - 2016-01-02 17:43 +1100
      Re: We will be moving to GitHub Chris Angelico <rosuav@gmail.com> - 2016-01-02 18:12 +1100
      Re: We will be moving to GitHub Marko Rauhamaa <marko@pacujo.net> - 2016-01-02 11:48 +0200
        Re: We will be moving to GitHub Chris Angelico <rosuav@gmail.com> - 2016-01-02 21:29 +1100
          Re: We will be moving to GitHub Marko Rauhamaa <marko@pacujo.net> - 2016-01-02 13:22 +0200
            Re: We will be moving to GitHub Chris Angelico <rosuav@gmail.com> - 2016-01-02 22:40 +1100
              Re: We will be moving to GitHub Marko Rauhamaa <marko@pacujo.net> - 2016-01-02 16:26 +0200
                Re: We will be moving to GitHub Chris Angelico <rosuav@gmail.com> - 2016-01-03 01:38 +1100
                  Re: We will be moving to GitHub Marko Rauhamaa <marko@pacujo.net> - 2016-01-02 16:52 +0200
                    Re: We will be moving to GitHub Chris Angelico <rosuav@gmail.com> - 2016-01-03 02:12 +1100
                      Re: We will be moving to GitHub Marko Rauhamaa <marko@pacujo.net> - 2016-01-03 02:33 +0200
                        Re: We will be moving to GitHub Chris Angelico <rosuav@gmail.com> - 2016-01-03 11:42 +1100
                          Re: We will be moving to GitHub Marko Rauhamaa <marko@pacujo.net> - 2016-01-03 03:14 +0200
                        Re: We will be moving to GitHub m <mvoicem@gmail.com> - 2016-01-04 11:13 +0100
                          Re: We will be moving to GitHub Marko Rauhamaa <marko@pacujo.net> - 2016-01-04 13:28 +0200
        Re: We will be moving to GitHub Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-04 23:53 +0100
      Re: We will be moving to GitHub Tim Chase <python.list@tim.thechases.com> - 2016-01-02 06:58 -0600
      Re: We will be moving to GitHub Michael Torrie <torriem@gmail.com> - 2016-01-02 20:24 -0700

#101115 — Re: We will be moving to GitHub

On Sat, Jan 2, 2016 at 6:58 AM, Zachary Ware
<zachary.ware+pylist@gmail.com> wrote:
>> It's not entirely clear whether that message is an acceptance of PEP 481
> or not.
>
> I've lost track of the pep numbers, but Brett's decision is final; the
> canonical CPython repository will be moving to GitHub in the near future.
> Note that we will *not* be using the GitHub issue tracker or wiki, just the
> hosting and review/pull request system. There are still several details to
> be worked out, though.

Okay, so that means it broadly is an acceptance of PEP 481. Hopefully
someone who's been involved in the discussions can check over the PEP
text and adjust as necessary to make it accurate to what's going to
happen.


On Sat, Jan 2, 2016 at 7:03 AM,  <paul.hermeneutic@gmail.com> wrote:
> Mark, it is good to know that a decision has been made so that we can move
> forward.
>
> Is there a summary document that discusses the options examined and why
> others did not meet the requirements? I am -NOT- trying to dredge up
> arguments about the choice. I am guessing that there have been some.
>
> If this fact-based decision was based solely on the fact that the BDFL
> prefers GitHub, please just say so. It is clear that git is a capable tool.

That's what the PEP is for. Here's the link:

https://www.python.org/dev/peps/pep-0481/

Yes, git is a capable tool. But so is Mercurial, and the arguments
weren't primarily based on differences in functionality (which are
pretty minor). It's mainly about the network effect.

ChrisA

[toc] | [next] | [standalone]

#101130

On Sat, 2 Jan 2016 07:09 am, Chris Angelico wrote:

> Yes, git is a capable tool. But so is Mercurial, and the arguments
> weren't primarily based on differences in functionality (which are
> pretty minor). It's mainly about the network effect.

You call it the network effect. I call it monoculture.

This decision is socially irresponsible. For all the cheap talk about
diversity, the Python core-devs are now about to move to (and probably give
money to) a company with a well-deserved reputation of being hostile to
women. Even if you believe that Github has reformed (and I see no credible
evidence that they have, apart from Github's own self-serving statements
that they have), diversity doesn't just apply to human individuals, it also
applies to technologies. The fact that Github is so popular should count
*against* it, not in favour.

There are times where everybody should do the same thing -- choosing whether
to drive on the left or the right side of the road, for example. And there
are times where following the crowd like lemmings is actively harmful, no
matter how convenient it seems in the short-run.


http://nedbatchelder.com/blog/201405/github_monoculture.html


Oh, and talking about DVCS:

https://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/





-- 
Steven

[toc] | [prev] | [next] | [standalone]

#101133

On Sat, Jan 2, 2016 at 5:43 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Sat, 2 Jan 2016 07:09 am, Chris Angelico wrote:
>
>> Yes, git is a capable tool. But so is Mercurial, and the arguments
>> weren't primarily based on differences in functionality (which are
>> pretty minor). It's mainly about the network effect.
>
> You call it the network effect. I call it monoculture.

The "you" here is the generic "you" rather than specifically
addressing me; I'm merely citing the discussions already given. I'm
going to assume that everyone here has read PEP 481, so if you
haven't, please go read it before responding.

https://www.python.org/dev/peps/pep-0481/

> This decision is socially irresponsible. For all the cheap talk about
> diversity, the Python core-devs are now about to move to (and probably give
> money to) a company with a well-deserved reputation of being hostile to
> women. Even if you believe that Github has reformed (and I see no credible
> evidence that they have, apart from Github's own self-serving statements
> that they have), diversity doesn't just apply to human individuals, it also
> applies to technologies. The fact that Github is so popular should count
> *against* it, not in favour.

If that is an argument, then it's one to push people to GitLab over
GitHub, but nothing about git vs hg.

> There are times where everybody should do the same thing -- choosing whether
> to drive on the left or the right side of the road, for example. And there
> are times where following the crowd like lemmings is actively harmful, no
> matter how convenient it seems in the short-run.

The popularity of technology IS an argument in its favour, though. How
many people here use Gopher instead of HTTP? Would it be better to
serve Python content on the obscure protocol rather than the popular
one? When 99% of people know how to use one technology and 1% know how
to use a different one, it's advantageous to go where the people are.
(Of course, there are other considerations, too - PHP is popular, but
that alone isn't a reason to use it. The context here is of
technologies so similar in functionality that we really CAN make a
decision on these kinds of bases.)

The Python project *needs* new contributors. This is not in question.
You can't expect to keep the project going solely on the basis of the
people currently writing and applying patches. So there are two
options:

1) Do everything using a workflow peculiar to Python, using a
less-popular technology
2) Put everything on a massively-popular web site using the more
popular technology, and do everything exactly the way everyone else
does.

Yes, the latter might be the lemming approach. But do we actually have
a problem with git and a pull-request workflow? (Concerns about GitHub
as a company are a separate consideration. As mentioned above, GitLab
is a similar option, and would allow python.org to host its own
instance if desired.) I have worked one-on-one with about 70 students
over the past two years, introducing them to Python and web
development, and using git and GitHub for their projects. They can now
go on to contribute to any of a huge number of projects. If, instead,
we'd taught them to use Mercurial, they still wouldn't be able to
immediately contribute to CPython, because the workflow is custom.
(You don't actually create a commit, you just use 'hg diff >patchfile'
and upload that. And if you're actually a core contributor, you need
to be careful about where you merge things, and which direction.)
Moving CPython to GitHub would mean anyone could simply fork it on the
server and push a commit, then paste a link into bugs.python.org and
let someone decide to merge it.

So which would you prefer? Arbitrary technological diversity, or a
large pool of potential contributors?

ChrisA

[toc] | [prev] | [next] | [standalone]

#101134

Steven D'Aprano <steve@pearwood.info>:

> Oh, and talking about DVCS:
>
> https://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-retur
> n-to-sanity/

It's interesting how different opinions people can have about version
control. I also have mine.

I have seen the paradise, which was Sun's Teamware. I haven't tried
Bitkeeper, it's successor.

Having struggled with Perforce, SVN and CVS, I was hopeful Mercurial
would be everything Teamware was.

Unfortunately, it wasn't. The big disappointment was the treatment of a
repository as the atomic unit.

Git's no better than Mercurial. Also, Git is conceptually cluttered.

Well, Git and Mercurial are not all that bad as long as only a single
person is working on the repository at any given time and you have a
strictly linear version history. That would be advisable anyway as you
should have a separate repository for each conceptual unit.


Marko

[toc] | [prev] | [next] | [standalone]

#101135

On Sat, Jan 2, 2016 at 8:48 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Having struggled with Perforce, SVN and CVS, I was hopeful Mercurial
> would be everything Teamware was.
>
> Unfortunately, it wasn't. The big disappointment was the treatment of a
> repository as the atomic unit.

You'll need to elaborate on this. Is a repository too large or too
small as an atomic unit? What is the Teamware style, and what is the
advantage? Remember, you can always build structures around the
outside of a repository - hg.python.org has half a dozen major repos,
plus a large number of others.

ChrisA

[toc] | [prev] | [next] | [standalone]

#101136

Chris Angelico <rosuav@gmail.com>:

> On Sat, Jan 2, 2016 at 8:48 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Having struggled with Perforce, SVN and CVS, I was hopeful Mercurial
>> would be everything Teamware was.
>>
>> Unfortunately, it wasn't. The big disappointment was the treatment of
>> a repository as the atomic unit.
>
> You'll need to elaborate on this. Is a repository too large or too
> small as an atomic unit?

If a repository contains independent changes, Hg and Git fail to
understand that the changes could be independent and force you to
resolve a merge conflict where no real conflict exists.

The whole philosophy of dependent and independent changes is
complicated; only Darcs has attempted to address the issue
scientifically (<URL: http://darcs.net/Theory/GaneshPatchAlgebra>).
However, Teamware chose an opportune approximation by treating each
file's version history independently.

Teamware's approach works nicely for backporting. You often fix a bug in
the development version and would like to propagate the fix to an older
version (= branch/stream/fork) of the product. In Teamware, the
propagation would not generate a conflict so it doesn't need to be
resolved. No special cherrypicking is involved, and afterwards, you
can't tell if the change was made first to the old
version/branch/stream/fork or the new one.

(Teamware didn't have branches. It always used forks. I believe Hg
is/was the same way. Git, which is what I have to use nowadays, has
branches but I find little use for them.)


Marko

[toc] | [prev] | [next] | [standalone]

#101137

On Sat, Jan 2, 2016 at 10:22 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> On Sat, Jan 2, 2016 at 8:48 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> Having struggled with Perforce, SVN and CVS, I was hopeful Mercurial
>>> would be everything Teamware was.
>>>
>>> Unfortunately, it wasn't. The big disappointment was the treatment of
>>> a repository as the atomic unit.
>>
>> You'll need to elaborate on this. Is a repository too large or too
>> small as an atomic unit?
>
> If a repository contains independent changes, Hg and Git fail to
> understand that the changes could be independent and force you to
> resolve a merge conflict where no real conflict exists.
>
> The whole philosophy of dependent and independent changes is
> complicated; only Darcs has attempted to address the issue
> scientifically (<URL: http://darcs.net/Theory/GaneshPatchAlgebra>).
> However, Teamware chose an opportune approximation by treating each
> file's version history independently.

I don't think you understand the meaning of "merge conflict", then. A
merge conflict is when you cannot simply merge the changes. If the
changes are on separate files, neither git nor hg will find this to be
a conflict, and the merge will happen automatically. Alternatively,
you can rebase rather than merging (git's term; Mercurial has a
similar concept for saying "put my private changes on top of the
history", but I can't remember the name), which again will succeed
automatically if the changes are to different files. Even better, the
merge/rebase will generally succeed even if the changes are to the
same file, as long as they're to different parts of it.

Play to a tool's strengths rather than its weaknesses, and you'll find
life a lot less frustrating. I'm fairly sure you could use the same
workflow with git as you were accustomed to with Teamware, only with a
few different names for things. And most likely Mercurial too, but
again, there'll be different names. Maybe you'll use branches for what
you used to use forks for, or maybe you'll have multiple clones of the
same repository, or maybe some other arrangement. Get to know some of
the myriad ways you can use modern source control systems, and find a
workflow that suits you.

ChrisA

[toc] | [prev] | [next] | [standalone]

#101144

Chris Angelico <rosuav@gmail.com>:

> I don't think you understand the meaning of "merge conflict", then. A
> merge conflict is when you cannot simply merge the changes.

A conflict is when there have been two parallel changes to the same
versioned target. In the case of Hg and Git, the whole repo is the
target.

> If the changes are on separate files, neither git nor hg will find
> this to be a conflict, and the merge will happen automatically.

They can propose to resolve the conflict automatically, which, BTW,
undermines the very idea of treating the whole repo as an atomic target.

Hg and Git think it's too dangerous to trust changes to individual files
are independent, but then, the alleviate the resulting pain, they offer
to treat the changes independently anyway, giving you the downsides
while sacrificing the (purported) upsides.

> Alternatively, you can rebase rather than merging (git's term;
> Mercurial has a similar concept for saying "put my private changes on
> top of the history", but I can't remember the name), which again will
> succeed automatically if the changes are to different files. Even
> better, the merge/rebase will generally succeed even if the changes
> are to the same file, as long as they're to different parts of it.

In Teamware, push ("putback") will simply succeed without any need to
resolve the merge conflict (automatically, or otherwise).

> Play to a tool's strengths rather than its weaknesses, and you'll find
> life a lot less frustrating. I'm fairly sure you could use the same
> workflow with git as you were accustomed to with Teamware, only with a
> few different names for things. And most likely Mercurial too, but
> again, there'll be different names. Maybe you'll use branches for what
> you used to use forks for, or maybe you'll have multiple clones of the
> same repository, or maybe some other arrangement. Get to know some of
> the myriad ways you can use modern source control systems, and find a
> workflow that suits you.

As I said, the problem is nonexistent when your repositories are tiny (~
5-20 files) and each is actively maintained by a single person.


Marko

[toc] | [prev] | [next] | [standalone]

#101148

On Sun, Jan 3, 2016 at 1:26 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> I don't think you understand the meaning of "merge conflict", then. A
>> merge conflict is when you cannot simply merge the changes.
>
> A conflict is when there have been two parallel changes to the same
> versioned target. In the case of Hg and Git, the whole repo is the
> target.

No, that's just a merge.

https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

ChrisA

[toc] | [prev] | [next] | [standalone]

#101149

Chris Angelico <rosuav@gmail.com>:

> On Sun, Jan 3, 2016 at 1:26 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> A conflict is when there have been two parallel changes to the same
>> versioned target. In the case of Hg and Git, the whole repo is the
>> target.
>
> No, that's just a merge.
>
> https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

Terminology aside, if I do this with Git:

       -----+--------------------+-------->
             \                   ^
              \pull             /push
               v               /
               +--------------+
                     edit

everything goes in without any further ado.

However, this operation will be blocked by Git:


       --+--+--------------------+----+--->
          \  \                   ^    X
           \  \pull             /push/
            \  v               /    /
         pull\ +--------------+    /push
              \      edit         /
               v                 /
               +-----------------+

Not so by Teamware as long as the pushes don't have files in common.


Marko

[toc] | [prev] | [next] | [standalone]

#101151

On Sun, Jan 3, 2016 at 1:52 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Terminology aside, if I do this with Git:
>
>        -----+--------------------+-------->
>              \                   ^
>               \pull             /push
>                v               /
>                +--------------+
>                      edit
>
> everything goes in without any further ado.
>
> However, this operation will be blocked by Git:
>
>
>        --+--+--------------------+----+--->
>           \  \                   ^    X
>            \  \pull             /push/
>             \  v               /    /
>          pull\ +--------------+    /push
>               \      edit         /
>                v                 /
>                +-----------------+
>
> Not so by Teamware as long as the pushes don't have files in common.

Ah, I see what you mean.

That's a constantly-debated point, and it's actually possible to make
git accept this, although it's not a normal workflow. Instead, you
just 'git pull' (possibly with --rebase) before you 'git push'. You
either create a new merge commit, or make it very clear that you are
changing your commits to pretend they were committed after the
already-pushed ones. Or you do a force-push and discard the other
commits (this is correct if you amended a commit). You HAVE to choose
because these are three viable solutions, and only a human can make
the decision.

Teamware presumably picked one of them, and doesn't give you the other
two choices. The price you pay for power is complexity. But with a
little bit of tooling, you can hide that complexity from day-to-day
usage - it means writing a git hook, but don't be scared off by that;
they're just simple scripts!

ChrisA

[toc] | [prev] | [next] | [standalone]

#101178

Chris Angelico <rosuav@gmail.com>:

> On Sun, Jan 3, 2016 at 1:52 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Terminology aside, if I do this with Git:
>>
>>        -----+--------------------+-------->
>>              \                   ^
>>               \pull             /push
>>                v               /
>>                +--------------+
>>                      edit
>>
>> everything goes in without any further ado.
>>
>> However, this operation will be blocked by Git:
>>
>>
>>        --+--+--------------------+----+--->
>>           \  \                   ^    X
>>            \  \pull             /push/
>>             \  v               /    /
>>          pull\ +--------------+    /push
>>               \      edit         /
>>                v                 /
>>                +-----------------+
>>
>> Not so by Teamware as long as the pushes don't have files in common.
>
> Ah, I see what you mean.
>
> That's a constantly-debated point, and it's actually possible to make
> git accept this, although it's not a normal workflow. Instead, you
> just 'git pull' (possibly with --rebase) before you 'git push'. You
> either create a new merge commit, or make it very clear that you are
> changing your commits to pretend they were committed after the
> already-pushed ones. Or you do a force-push and discard the other
> commits (this is correct if you amended a commit). You HAVE to choose
> because these are three viable solutions, and only a human can make
> the decision.
>
> Teamware presumably picked one of them,

Teamware didn't have to pick any of them since Teamware's commits were
done per individual files. The repository didn't have a commit history.

Thus, Teamware was equivalent to Hg/Git with each file treated as an
independent repository.


Marko

[toc] | [prev] | [next] | [standalone]

#101180

On Sun, Jan 3, 2016 at 11:33 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> That's a constantly-debated point, and it's actually possible to make
>> git accept this, although it's not a normal workflow. Instead, you
>> just 'git pull' (possibly with --rebase) before you 'git push'. You
>> either create a new merge commit, or make it very clear that you are
>> changing your commits to pretend they were committed after the
>> already-pushed ones. Or you do a force-push and discard the other
>> commits (this is correct if you amended a commit). You HAVE to choose
>> because these are three viable solutions, and only a human can make
>> the decision.
>>
>> Teamware presumably picked one of them,
>
> Teamware didn't have to pick any of them since Teamware's commits were
> done per individual files. The repository didn't have a commit history.
>
> Thus, Teamware was equivalent to Hg/Git with each file treated as an
> independent repository.

And what if you and someone else edit different parts of the same
file? How is that handled? Why should the top and bottom of one file
be dramatically different from two separate files?

ChrisA

[toc] | [prev] | [next] | [standalone]

#101181

Chris Angelico <rosuav@gmail.com>:

> On Sun, Jan 3, 2016 at 11:33 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Teamware didn't have to pick any of them since Teamware's commits
>> were done per individual files. The repository didn't have a commit
>> history.
>>
>> Thus, Teamware was equivalent to Hg/Git with each file treated as an
>> independent repository.
>
> And what if you and someone else edit different parts of the same
> file? How is that handled? Why should the top and bottom of one file
> be dramatically different from two separate files?

Files are a natural unit of granularity; that's why we don't place all
source code in a single source code file.

There are exceptions, but in general I'd say only one person should be
editing one file at any given time.

As I mentioned before, Darcs tries to eat the cake and have it, too. It
provides Git-like repository semantics and a clearly defined concept of
parallel changes. It does *not* make a distinction between two files and
two parts of a file.

Unfortunately, rumor has it that Darcs can run into serious performance
issues as it enforces the conceptual purity. That's why I think
Teamware's file-level focus is the practical sweet spot of distributed
version control.


Marko

[toc] | [prev] | [next] | [standalone]

#101241

W dniu 03.01.2016 o 01:33, Marko Rauhamaa pisze:
> Teamware didn't have to pick any of them since Teamware's commits were
> done per individual files. The repository didn't have a commit history.
> 
> Thus, Teamware was equivalent to Hg/Git with each file treated as an
> independent repository.
> 

It sounds like CVS.

How can you be sure that your code is consistent if each of your file
has it's own, independent history? Use tags like in CVS?

r. m.

[toc] | [prev] | [next] | [standalone]

#101243

m <mvoicem@gmail.com>:

> W dniu 03.01.2016 o 01:33, Marko Rauhamaa pisze:
>> Teamware didn't have to pick any of them since Teamware's commits were
>> done per individual files. The repository didn't have a commit history.
>>
>> Thus, Teamware was equivalent to Hg/Git with each file treated as an
>> independent repository.
>>
>
> It sounds like CVS.

The main problem with CVS is that these operations don't commute:

                                       *
                edit                   :
       ----+--------------+--------------->
            \              \           :
             \              \          :
              \branch        \merge    :
               \              \        :
                v              v       :
                +--------------+---------->
                                       :
                                       :
                                       :
                                       :
       ----+-------------------+---------->
            \                  ^       :
             \                /        :
              \branch        /merge    :
               \            /          :
                v   edit   /           :
                +---------+--------------->
                                       :


If you look at the edited file at *, CVS reveals the merge direction in
the version history. In Teamware, you can't see afterwards, which way
the change was made ("branches" and "merges" are not recorded).

Additionally, CVS doesn't make the distinction between commits and
merges, which both Hg/Git and Teamware do. The distinction could be
emulated in CVS (as well as, say, Perforce) but very awkwardly.

> How can you be sure that your code is consistent if each of your file
> has it's own, independent history? Use tags like in CVS?

Yes, tags ("checkpoints") can be used, although I don't remember us
using them. Rather, we used distinct clones for tagging.


Marko

[toc] | [prev] | [next] | [standalone]

#101248

Marko Rauhamaa wrote:

> Well, Git and Mercurial are not all that bad as long as only a single
> person is working on the repository at any given time and you have a
> strictly linear version history.

I cannot confirm your observations(?) for Git.  There was a time when three 
of four people of our team (me included) were working in the same and in 
different branches of the same repository without any serious problem 
(occasional merge conflicts cannot be avoided in such a scenario, of 
course).  The resulting commit tree was fascinating to us :)

Also, that Git appears to work well with Linux kernel development (for which 
it was created) where probably hundreds of developers, if not more, are 
working on at the same time, casts into doubt the correctness of your 
statement, and the amount of your work experience with Git.

> That would be advisable anyway as you should have a separate repository
> for each conceptual unit.

Apples and oranges.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#101158

On 2016-01-02 17:43, Steven D'Aprano wrote:
> Oh, and talking about DVCS:
> 
> https://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/

The arguments there are pretty weak.

Not working offline?  I use that *ALL* *THE* *TIME*.  Maybe the
author lives some place where the main internet connection doesn't go
down for a week because some dim bulb at AT&T disconnected the wrong
cable and failed to log the fact. Maybe the author is willing to shell
out highway-robbery prices for wifi on an airplane just to access repo
history.  Maybe the author has an unlimited data plan and good
coverage.  But for me, disconnected usage (along with the much
easier/smarter branching & merging) is one of the indispensable
features.  Just because the author doesn't use a feature, doesn't
mean it's useful.

Consider the author's case for storing large binary blobs in a VCS
and then not wanting to check out the entire repo.  However, to
use/tweak the logic & phrasing of the article, "Let me tell you
something. Of all the time I have ever used DVCSes, over the last 15
years if we count dropping large binary files in a shared folder and
eight or so if you don’t, I have wanted to store large binary files
in the repository a grand total of maybe about zero times. And this
is merely going down over time as CPU, memory, and storage capacity
ever increases. If you work as a CGI animator/artist, or produce
audio, or don't know what you're doing because you're storing
generated output, then okay, sure, this is a huge feature for you.
But for the rest of us, I am going to assert that this is not the use
case you need to optimize for when choosing a VCS."

So while I don't really have dog in the fight of
git-vs-hg-vs-bzr-vs-fossil or the
GitHub-vs-Bitbucket-vs-GitLab-vs-privately-hosted fight, I find the
logic of that article as strained as when I first read it.

-tkc

[toc] | [prev] | [next] | [standalone]

#101185

On 01/01/2016 11:43 PM, Steven D'Aprano wrote:
> On Sat, 2 Jan 2016 07:09 am, Chris Angelico wrote:
> 
>> Yes, git is a capable tool. But so is Mercurial, and the arguments
>> weren't primarily based on differences in functionality (which are
>> pretty minor). It's mainly about the network effect.
> 
> You call it the network effect. I call it monoculture.

Indeed. The whole purpose of git is to allow development to be
distributed.  Is it a matter of hosting space?  Is it too expensive for
python.org to host their own public-facing git repository?  Especially
if python.org has no plans to use github's issue tracker this move makes
little sense to me.  A pull request can be made from any developer's own
git repository without github, or even from github if other developers
really want to work there.

I can understand why OSS projects like github given its complete
project-management options.  But if it's just the repository you're
after, I get far more mileage from my own locally-hosted git
repositories.  It's not at all hard to push to a read-only public http
git repository.  Pull requests can be made against individual
developers' http repos or hosted git providers.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web