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 ou
m :
> 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 repo
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.
>
Michael Torrie writes:
> On 01/02/2016 12:02 AM, Ben Finney wrote:
> > GitHub's “pull request” workflow is entirely proprietary and can
> > only be done within GitHub.
>
> Really? This seems like an entirely artificial github requirement.
Yes, it is.
> There's absolutely no reason why github c
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.
On 01/02/2016 12:02 AM, Ben Finney wrote:
> What is being done to stave off the common response, addressed by GitHub
> users to people submitting a change as a link to their Git repository,
> of “can you please submit that as a GitHub pull request”?
>
> That common response makes for an unnecessar
Chris Angelico :
> On Sun, Jan 3, 2016 at 11:33 AM, Marko Rauhamaa 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
On Sun, Jan 3, 2016 at 11:33 AM, Marko Rauhamaa 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
On 01/01/2016 19:39, Mark Lawrence wrote:
Please see
https://mail.python.org/pipermail/core-workflow/2016-January/000345.html
This should encourage developers at all levels to help out, such that
the list of open issues on the bug tracker falls drastically.
One thing that I forgot is that if
Chris Angelico :
> On Sun, Jan 3, 2016 at 1:52 AM, Marko Rauhamaa wrote:
>> Terminology aside, if I do this with Git:
>>
>>-++>
>> \ ^
>> \pull /push
>>v /
>>
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
On Sun, Jan 3, 2016 at 1:52 AM, Marko Rauhamaa wrote:
> Terminology aside, if I do this with Git:
>
>-++>
> \ ^
> \pull /push
>v /
>+--+
>
Chris Angelico :
> On Sun, Jan 3, 2016 at 1:26 AM, Marko Rauhamaa 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-Bran
On Sun, Jan 3, 2016 at 1:26 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> 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 tar
On Sat, Jan 2, 2016 at 5:12 AM, Chris Angelico wrote:
> On Sat, Jan 2, 2016 at 5:43 PM, Steven D'Aprano wrote:
>> 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
Chris Angelico :
> 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.
>
On Sat, Jan 2, 2016 at 10:22 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Sat, Jan 2, 2016 at 8:48 PM, Marko Rauhamaa wrote:
>>> Having struggled with Perforce, SVN and CVS, I was hopeful Mercurial
>>> would be everything Teamware was.
>>>
>>> Unfortunately, it wasn't. The big disappointm
Chris Angelico :
> On Sat, Jan 2, 2016 at 8:48 PM, Marko Rauhamaa 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.
>
>
On Sat, Jan 2, 2016 at 8:48 PM, Marko Rauhamaa 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
Steven D'Aprano :
> 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 tri
On Sat, Jan 2, 2016 at 5: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
Terry Reedy writes:
> On 1/1/2016 4:08 PM, Zachary Ware wrote:
> > There were three reasons given in Brett's decision message:
> >
> > 1. No major distinguishing features between GitHub or GitLab
It seems “complete source code available and freely licensed, allowing
the community to implemen
Zachary Ware writes:
> On Jan 1, 2016 2:35 PM, "Paul Rubin" wrote:
> > Will everyone wanting to submit patches be required to use a Github
> > account? Or will it be enough to put the patch in an outside repo
> > and link to it in the Python issue tracker? I'm glad that (it sounds
> > like) no G
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
Terry Reedy writes:
> While the decision might not be my personal first choice, we
> absolutely need more core developers contributing, including reviewing
> contributed patches.
Yeah, I'm not delighted by the choice either, but as long as the core
devs have bought in and it doesn't affect non-co
On 1/1/2016 4:08 PM, Zachary Ware wrote:
On Fri, Jan 1, 2016 at 2:03 PM, wrote:
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.
Ea
Zachary Ware writes:
> Correct, no GitHub account will be required for interactions on the
> bugs.python.org tracker, and a patch can move all the way through to commit
> entirely on the b.p.o tracker (just as currently).
Thanks.
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, Jan 1, 2016 at 2:03 PM, wrote:
> 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.
Easiest would be to look through the arch
On 01/01/2016 20:03, paul.hermeneu...@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
On Jan 1, 2016 2:35 PM, "Paul Rubin" wrote:
>
> Zachary Ware writes:
> > ... 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.
>
> Will everyone
Zachary Ware writes:
> ... 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.
Will everyone wanting to submit patches be required to use a Github
acc
On Sat, Jan 2, 2016 at 6:58 AM, Zachary Ware
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 th
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
On Jan 1, 2016 1:47 PM, "Chris Angelico" wrote:
>
> On Sat, Jan 2, 2016 at 6:39 AM, Mark Lawrence
wrote:
> > Please see
> > https://mail.python.org/pipermail/core-workflow/2016-January/000345.html
> >
> > This should encourage developers at all levels to help out, such that
the
> > list of open i
On Sat, Jan 2, 2016 at 6:39 AM, Mark Lawrence wrote:
> Please see
> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html
>
> This should encourage developers at all levels to help out, such that the
> list of open issues on the bug tracker falls drastically.
How does that inte
Please see
https://mail.python.org/pipermail/core-workflow/2016-January/000345.html
This should encourage developers at all levels to help out, such that
the list of open issues on the bug tracker falls drastically.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what
36 matches
Mail list logo
