On Sun, Aug 05, 2012 at 05:35:47PM -0400, Kenneth R Westerback wrote:
> On Sun, Aug 05, 2012 at 03:00:04PM -0400, Ted Unangst wrote:
> > On Sun, Aug 05, 2012 at 10:46, Darrin Chandler wrote:
> > > On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote:
> > >> Well, git just has a different set
> git sucks. mercurial ruleZ, i want a mercurial mirror.
> And python in base... and some icecream.
>
python and mercurial sucks both. Both have nothing to do with true UNIX
heritage. Use Ubuntu
git sucks. mercurial ruleZ, i want a mercurial mirror.
And python in base... and some icecream.
André
2012/8/6 Franco Fichtner :
> On Aug 6, 2012, at 12:02 PM, Marc Espie wrote:
>
>> Well, I have an actual list of advantages that git may offer:
>
> Thanks, Marc. Good listing! I wonder what CVS b
On Aug 6, 2012, at 12:02 PM, Marc Espie wrote:
> Well, I have an actual list of advantages that git may offer:
Thanks, Marc. Good listing! I wonder what CVS brings to the table on the
bright side?
I understand everything that's been said. I've even come to hate GPL'ed
software just because of u
Well, I have an actual list of advantages that git may offer:
- better patch/diff handling capabilities. CVS is very crappy at that.
As soon as you are testing stuff locally, every update request will produce
conflicts. git has very good merging capabilities, comparatively.
- possibility to hav
On Sun, Aug 05, 2012 at 02:14:56PM -0600, Theo de Raadt wrote:
> > I don't find this controversial, except the notion that sticking with
> > blunt tools to solve a human/procedural problem is a good idea.
>
> How else should I, as the maintainer of the trunk, contain the damage
> from these human/
On Sun, Aug 05, 2012 at 03:00:04PM -0400, Ted Unangst wrote:
> On Sun, Aug 05, 2012 at 10:46, Darrin Chandler wrote:
> > On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote:
> >> Well, git just has a different set of bugs than cvs.
> > ...
> >> I would deem cvs MORE painful than git on avera
> I don't find this controversial, except the notion that sticking with
> blunt tools to solve a human/procedural problem is a good idea.
How else should I, as the maintainer of the trunk, contain the damage
from these human/procedural problems? Careful -- every suggestion you
want to suggest now
On Sun, Aug 05, 2012 at 03:00:04PM -0400, Ted Unangst wrote:
> I will add a somewhat controversial viewpoint to the mix. Because cvs
> makes working with branches and large diffs so painful, it forces
> developers to split their work into smaller pieces. In OpenBSD,
> that's a good thing. Keepin
On Sun, Aug 05, 2012 at 10:46, Darrin Chandler wrote:
> On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote:
>> Well, git just has a different set of bugs than cvs.
> ...
>> I would deem cvs MORE painful than git on average, it's just that
>> we're more accustomed to the pain...
>
> Yes, th
On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote:
> Well, git just has a different set of bugs than cvs.
...
> I would deem cvs MORE painful than git on average, it's just that
> we're more accustomed to the pain...
Yes, this is right. And also there would be a price to pay in lost
produ
On 2012-08-04, Tony wrote:
> Personally I'd love to make a fork and contribute back a ton of pull
> requests, mostly on the documentation side though.
No need for all this complication of exporting/syncing between
the version control system used by OpenBSD and another one for work
directories - j
On Sat, Aug 4, 2012 at 6:43 AM, Tony wrote:
> Personally I'd love to make a fork and contribute back a ton of pull
> requests, mostly on the documentation side though.
What's easier/nicer about github's pull request than sending an email
with an enclosed diff?
I use git for a lot of my local dev
On Sat, Aug 04, 2012 at 05:47:47PM +0200, Janne Johansson wrote:
> Also, diffs from git has proven to not apply cleanly at times (for
> reasons unknown to me), so whatever you hope the versioning tool will
> let you do, don't forget to make sure any contributions do apply.
Well, git just has a dif
Also, diffs from git has proven to not apply cleanly at times (for
reasons unknown to me), so whatever you hope the versioning tool will
let you do, don't forget to make sure any contributions do apply.
We will not do that for you, just to accommodate different VC systems
that people fancy at the
You don't have to ask permission to anyone to do whatever you want
with the OpenBSD code. If you can create a github account that
reliably mirror OpenBSD's commits, I think some people would be
interested.
For what is worth, there is already a git repository that follows
OpenBSD: http://anoncvs.es
No.
This has been discussed many times before, and we have no interest in
this.
On 2012 Aug 04 (Sat) at 15:43:37 +0200 (+0200), Tony wrote:
:Hey!
:
:Guys, what do you think about putting OpenBSD on GitHub? I see you guys
:already have an account there so I just thought I'd ask:
:https://github.c
17 matches
Mail list logo
