There was a flurry of activity about potentially switching from
Mercurial to Git at the beginning of the year. The topic seems to have
died down. Can I assume that this means Mercurial won the debate and
that we will not be switching from Mercurial to Git – even though
BitBucket is now a Git reposi
Russel,
I would say inertia postponed a decision.
I'd like to change to git, but it's not a high priority.
I'd like to get py2/3 work done and released and then revisit.
-Bill
On Mon, May 9, 2016 at 5:42 AM, Russel Winder wrote:
> There was a flurry of activity about potentially switching from
For me, scons is the ONLY project I work on that uses Mercurial, and
having to translate each and every command is a real pain.
I¹ve also NOT contributed back many changes I¹ve made to get Python to
build properly on old UNIX systems, primarily because it was using Hg.
I doubt I¹m alone in this, a
> On May 9, 2016, at 07:57 , Rob Boehne wrote:
>
> For me, scons is the ONLY project I work on that uses Mercurial, and
> having to translate each and every command is a real pain.
> I¹ve also NOT contributed back many changes I¹ve made to get Python to
> build properly on old UNIX systems, prim
All,
So it sounds like (from limited consensus), that switching to Git now,
would remove a significant barrier to contributing code/fixes?
-Bill
On Mon, May 9, 2016 at 8:12 AM, Tim Jenness wrote:
>
> > On May 9, 2016, at 07:57 , Rob Boehne wrote:
> >
> > For me, scons is the ONLY project I wo
I too think that switching to git would help get changes/fixes in faster and
easier.
HG is not that different from Git but having to install and configure another
DVCS is a cognitive load that would be nice to not have to deal with.
Cheers,
Ben
On Monday, May 9, 2016 10:13 AM, Bill Deegan
On Mon, 2016-05-09 at 10:13 -0700, Bill Deegan wrote:
> All,
>
> So it sounds like (from limited consensus), that switching to Git
> now,
> would remove a significant barrier to contributing code/fixes?
>
We just need to be careful that Git supporters are quick and vocal,
whereas Mercurial folk
Hi there,
On 09.05.2016 16:57, Rob Boehne wrote:
For me, scons is the ONLY project I work on that uses Mercurial, and
having to translate each and every command is a real pain.
I¹ve also NOT contributed back many changes I¹ve made to get Python to
build properly on old UNIX systems, primarily be
> On May 9, 2016, at 12:39 , Dirk Bächle wrote:
>
>
> I understand that for you, and Tim, using git it would be less of a hindrance
> to simply
> "check in" the changes and extensions for SCons that you seem to have in the
> hopper.
> But I'm interested in increasing activity in the "long run
It would certainly make it easier for me to contribute; not that I've had
that much to contribute recently, but git is in my fingers now and I have
to remind myself how to do things in hg.
On Mon, May 9, 2016 at 1:13 PM, Bill Deegan
wrote:
> All,
>
> So it sounds like (from limited consensus), t
Hmm.
I've used (in order, more or less), PLS (which I expect nobody to know),
Clearcase, RCS, CVS, Arch,
TLA, HG, BZR, and Git. I won't claim to have used svn in any real sense.
The first 4 of that list were centralized version control systems and so not
applicable to this
discussion.
Of ar
Hi Mark,
On 10.05.2016 04:21, Mark A. Flacy wrote:
Hmm.
I've used (in order, more or less), PLS (which I expect nobody to know),
Clearcase, RCS, CVS, Arch, TLA, HG, BZR, and Git. I won't
claim to have used svn in any real sense.
The first 4 of that list were centralized version control system
I'd say that git is perfectly happy with multiple heads in a given repository
while hg is pretty
cranky with that setup. Or at least it was when I last used hg.
Once you've pushed something to an external repository with git, the history is
pretty much
unmutable. You'd have to convince the r
There has been at least one case where I discovered a small issue with
SCons and went to go submit a pull request, but then remembered SCons uses
hg, and decided it wasn't worth the effort to install hg, and learn the
differences between it and Git.
Is this a case of laziness? Perhaps. But I suspe
> On May 11, 2016, at 07:23 , Jonathon Reinhart
> wrote:
>
> There has been at least one case where I discovered a small issue with SCons
> and went to go submit a pull request, but then remembered SCons uses hg, and
> decided it wasn't worth the effort to install hg, and learn the difference
I'm git user, and I feel pain each time there is a need to contribute to
scons.
I believe, that moving to git + github could get scons going and get
attention of much more persons/potential contributors (majority of devs
uses git and GH seems to be more popular than BB these days). I had a
chance
On Mon, May 9, 2016 at 8:13 PM, Bill Deegan wrote:
> All,
>
> So it sounds like (from limited consensus), that switching to Git now, would
> remove a significant barrier to contributing code/fixes?
No. Let's run a Git mirror and see how many fixes will end up there.
HG is able to pull them,
_
To sum up my opinion - I am not against going to Git+GitHub, but only
when current repository history is cleaned up of the garbage, such as
DocBook templates and is kept small of that garbage and binary files.
SCons repository size shows that it is untidy mess.
_
+1 from me for the idea of a git mirror...like this we could have both worlds
combined. And we would see twice as much contributions as before. ;)
Dirk
Am 12. Mai 2016 09:27:12 MESZ, schrieb anatoly techtonik :
>On Mon, May 9, 2016 at 8:13 PM, Bill Deegan
>wrote:
>> All,
>>
>> So it sounds lik
Sorry...¨twice as many¨, duh.
Dirk
Am 12. Mai 2016 11:12:19 MESZ, schrieb Dirk Baechle :
>+1 from me for the idea of a git mirror...like this we could have both
>worlds combined. And we would see twice as much contributions as
>before. ;)
>
>Dirk
>
>
>Am 12. Mai 2016 09:27:12 MESZ, schrieb anatol
Russel Winder wrote:
> There was a flurry of activity about potentially switching from
> Mercurial to Git at the beginning of the year. The topic seems to have
> died down. Can I assume that this means Mercurial won the debate and
> that we will not be switching from Mercurial to Git – even though
Dirk Bächle writes:
> I *don't* want the history in my repos to be mutable...maybe that's
> why git doesn't seem to be so more powerful than hg to me, and why I
> still consider them to be "on par" regarding functionality. At least
> for the work I have to do with them...
For immutability lovers
On Wed, 2016-11-23 at 21:19 +0100, Saša Janiška wrote:
> […]
>
> For immutability lovers I can only recommend: Fossil
> (http://fossil-scm.org/) - I use it for *all* my personal stuff, but
> for
> public projects it seems that Git won the battle (although I’m
> waiting
> that Fossil gets something
Dirk Bächle writes:
> I *don't* want the history in my repos to be mutable...
All of the major Git hosting providers have *protected branches* which are
immutable.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listin
On Fri, 2016-11-25 at 18:42 -0500, Jonathon Reinhart wrote:
> Dirk Bächle writes:
>
> > I *don't* want the history in my repos to be mutable...
>
> All of the major Git hosting providers have *protected branches*
> which are
> immutable.
But isn't that a red herring? Git hosters are just a fina
On Sun, Nov 27, 2016 at 11:59 AM, Russel Winder
wrote:
> On Fri, 2016-11-25 at 18:42 -0500, Jonathon Reinhart wrote:
> > Dirk Bächle writes:
> >
> > > I *don't* want the history in my repos to be mutable...
> >
> > All of the major Git hosting providers have *protected branches*
> > which are
>
On Sun, 2016-11-27 at 12:39 +0100, rupert THURNER wrote:
Absolutely no reason to apologise for contributing.
> sorry for posting here, i usually just lurk on this list because i am
> interested in build tools. i doubt that mercurial will die out -
> their
> mailing list seems more busy than ever.
> The point here is that someone can mutate a branch locally and then
force it to the mainline.
No, that is specifically what protected branches prevent. If "master" is
protected, then no one, not even an admin, can re-write history and force
push to it.
Personally, I find the rewriting extremely
On Sun, 2016-11-27 at 14:11 -0500, Jonathon Reinhart wrote:
> > The point here is that someone can mutate a branch locally and then
>
> force it to the mainline.
>
> No, that is specifically what protected branches prevent. If "master"
> is
> protected, then no one, not even an admin, can re-writ
On Nov 28, 2016 10:42, "Russel Winder" wrote:
>
> On Sun, 2016-11-27 at 14:11 -0500, Jonathon Reinhart wrote:
> > Personally, I find the rewriting extremely powerful for my local
> > development - I can re-arrange, split, and join commits in my feature
> > branch before it is merged into master. V
On Mon, Nov 28, 2016 at 4:42 AM, Russel Winder wrote:
> On Sun, 2016-11-27 at 14:11 -0500, Jonathon Reinhart wrote:
>> > The point here is that someone can mutate a branch locally and then
>>
>> force it to the mainline.
>>
>> No, that is specifically what protected branches prevent. If "master"
>
31 matches
Mail list logo