On 31 October 2016 at 16:35, Daniel J. Luke wrote:
> On Oct 31, 2016, at 11:29 AM, Ryan Schmidt wrote:
>>
>> One of the suggestions in this thread was to use the "hub" wrapper around
>> git. Based on the fact that their homepage only mentions how to install hub
>> with Homebrew, and that they hav
If you had a personal directory in the users directory of the Subversion
repository, that has now been converted to a separate git repository in
https://github.com/macports with a name starting with "macports-user-".
We suggest that you move your user repository to your own GitHub account where
I just wanted to try out the new git setup to make sure things were working
for me, and this was a simple little thing to do.
On Mon, Oct 31, 2016 at 7:10 PM, Brandon Allbery
wrote:
>
> On Mon, Oct 31, 2016 at 10:05 PM, Lawrence Velázquez
> wrote:
>
>> new 8ed388e berkeleygw: Remove svn $Id$ li
On Mon, Oct 31, 2016 at 10:05 PM, Lawrence Velázquez
wrote:
> new 8ed388e berkeleygw: Remove svn $Id$ line.
btw, given that it's not being automated because of the unnecessary builds
it would trigger, I would say don't bother making commits that *only*
remove the Id line. It's not harmful; it's
Thanks, yes I just realized I hadn't set that up.
David
On Mon, Oct 31, 2016 at 7:05 PM, Lawrence Velázquez
wrote:
> You should set your repository's user.email to your MacPorts email address.
>
> vq
>
> On Oct 31, 2016, at 9:50 PM, dstrubbe
> wrote:
>
> dstrubbe pushed a commit to branch mast
You should set your repository's user.email to your MacPorts email address.
vq
> On Oct 31, 2016, at 9:50 PM, dstrubbe
> wrote:
>
> dstrubbe pushed a commit to branch master
> in repository macports-ports.
>
> https://github.com/macports/macports-ports/commit/8ed388e541ce01d92d698791fefd72a4b
On 2016-11-01 01:03, Ryan Schmidt wrote:
> On Oct 31, 2016, at 17:17, Dan Ports wrote:
>>
>> Any reason not to just bulk-remove them all at once?
>
> That would probably tie up the buildbot for weeks or months. We could
> cancel those builds, but even the act of scheduling 20,000 builds per
> bu
On Mon, Oct 31, 2016 at 07:03:24PM -0500, Ryan Schmidt wrote:
> On Oct 31, 2016, at 17:17, Dan Ports wrote:
> >
> > Any reason not to just bulk-remove them all at once?
>
> That would probably tie up the buildbot for weeks or months. We could cancel
> those builds, but even the act of schedulin
You can even configure so that becomes the default for "git pull" for that
repo.
git config --local --bool pull.rebase true
git config --local --bool rebase.autoStash true
On Mon, Oct 31, 2016 at 7:08 PM, Eric A. Borisch
wrote:
> I hoped someone would point me to a command like this. Thanks!
>
On Oct 31, 2016, at 17:17, Dan Ports wrote:
>
> Any reason not to just bulk-remove them all at once?
That would probably tie up the buildbot for weeks or months. We could cancel
those builds, but even the act of scheduling 20,000 builds per builder is much
more than we've ever attempted before
I hoped someone would point me to a command like this. Thanks!
- Eric
On Monday, October 31, 2016, Joshua Root wrote:
>
> I'm using 'git pull --rebase --autostash' which does the stash-before and
> pop-after automatically.
>
> - Josh
>
___
macports-d
On 2016-11-1 09:21 , Lawrence Velázquez wrote:
The only downside of running "portindex" manually
is that you have to pass the location of the ports tree as an argument.
Or cd there first. If you're working on a ports tree you'll often be in
the right place already.
- Josh
___
> On Oct 31, 2016, at 6:17 PM, Dan Ports wrote:
>
> Any reason not to just bulk-remove them all at once?
No reason other than time and effort.
vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/list
> On Oct 31, 2016, at 5:55 PM, Lawrence Velázquez wrote:
>
>> On Oct 31, 2016, at 5:50 PM, Sean Farley wrote:
>>
>> I'm not sure I agree with attempting to modify the git repo at all. For
>> example, what if I'm in the middle of bisecting and need to add/remove a
>> port? Why does 'port sync' c
Any reason not to just bulk-remove them all at once?
Dan
On Mon, Oct 31, 2016 at 05:30:07PM -0400, Lawrence Velázquez wrote:
> Hi,
>
> We no longer have use for "$Id" lines, so committers should remove them at
> their convenience.
>
> vq
>
> > On Oct 31, 2016, at 5:20 PM, Schamschula
> > wr
So, now I ran *again* into a problem with my local install after self updating
it just now:
---
$ port -v rev-upgrade
---> Scanning binaries for linking errors
Warning: Error parsing file /opt/local/bin/cdda2wav: Error opening or reading
file
Warning: Error parsing file /opt/local/bin/cdrecord:
Lawrence Velázquez writes:
>> On Oct 31, 2016, at 5:50 PM, Sean Farley wrote:
>>
>> I'm not sure I agree with attempting to modify the git repo at all. For
>> example, what if I'm in the middle of bisecting and need to add/remove a
>> port? Why does 'port sync' call at all what the state is?
>
On 2016-11-1 08:46 , Lawrence Velázquez wrote:
On Oct 31, 2016, at 5:01 PM, Eric A. Borisch wrote:
5) 'push' changes (to macports-ports)
Oh, and and to capture upstream changes, somewhere after 1 and before
5 (4? 3?),
a) git fetch
b) git rebase origin/master
It looks like git pull --rebase do
Ryan Schmidt writes:
> I don't want to understand git's theory or to be given lots of options
> amongst which to choose; I just want to be told how to get my work done.
I had a thoroughly good chuckle reading this. It is the number one sin
of the design of git, IMHO.
___
> On Oct 31, 2016, at 5:50 PM, Sean Farley wrote:
>
> I'm not sure I agree with attempting to modify the git repo at all. For
> example, what if I'm in the middle of bisecting and need to add/remove a
> port? Why does 'port sync' call at all what the state is?
Updating the repository is the whol
"Eric A. Borisch" writes:
> Thanks for all the hard work with this transition! I'm sure once we're all
> "over the hump" we'll look back and wonder why we waited so long.
>
> Just so I'm clear on this, is the desired approach for each committer to:
>
> == setup ==
> 1) clone macports/macports-por
> On Oct 31, 2016, at 5:46 PM, Lawrence Velázquez wrote:
>
> Ultimately, anything you do before pushing is up to you, as long as
> you don't push any merge commits. We've disabled force-pushing on all
> master branches, so you don't have to worry too much doing that
> accidentally.
That is to sa
> On Oct 31, 2016, at 5:01 PM, Eric A. Borisch wrote:
>
> Just so I'm clear on this, is the desired approach for each committer
> to:
>
> == setup ==
> 1) clone macports/macports-ports to the local filesystem
After cloning, you should be sure that you are using your MacPorts email
address for c
Larry,
OK. Will do.
On Oct 31, 2016, at 4:30 PM, Lawrence Velázquez wrote:
> Hi,
>
> We no longer have use for "$Id" lines, so committers should remove them at
> their convenience.
>
> vq
>
>> On Oct 31, 2016, at 5:20 PM, Schamschula
>> wrote:
>>
>> Schamschula pushed a commit to branch
Hi,
We no longer have use for "$Id" lines, so committers should remove them at
their convenience.
vq
> On Oct 31, 2016, at 5:20 PM, Schamschula
> wrote:
>
> Schamschula pushed a commit to branch master
> in repository macports-ports.
>
> https://github.com/macports/macports-ports/commit/eee
You can `pull -r` immediately before pushing. Conveniently, you can
configure pull to autorebase. Either way, the simplest modification to
your last step is this:
git pull -r && git push
On 10/31/2016 05:01 PM, Eric A. Borisch wrote:
> Thanks for all the hard work with this transition! I'm sure
Thanks for all the hard work with this transition! I'm sure once we're all
"over the hump" we'll look back and wonder why we waited so long.
Just so I'm clear on this, is the desired approach for each committer to:
== setup ==
1) clone macports/macports-ports to the local filesystem
== every chan
On Mon, Oct 31, 2016 at 08:08:26PM +0100, Marko Käning wrote:
> Doesn’t the second build of jasper justify the revbump, or should we
> simply ignore this and let rev-upgrade take care of it??
The revbump is justified. Your commit message should have mentioned why
it was necessary, though.
--
Cle
On 31 Oct 2016, at 21:14 , Lawrence Velázquez wrote:
>> On Oct 31, 2016, at 5:23 AM, Marko Käning wrote:
>>
>> a post-commit-hook checking whether the GitHub pull request ID #123
>> actually exists for the main repository seems like a valuable feature,
>> especially in the transition phase. Sh
> On Oct 31, 2016, at 5:23 AM, Marko Käning wrote:
>
> a post-commit-hook checking whether the GitHub pull request ID #123
> actually exists for the main repository seems like a valuable feature,
> especially in the transition phase. Shall I file a ticket on trac for it?
Sure, if you like. Feel
On 2016-11-1 06:34 , Marko Käning wrote:
On 31 Oct 2016, at 20:25 , Joshua Root wrote:
Depends on the nature of the breakage, which is not shown above. The only
dependency is jpeg, which has not changed in some time. My jasper installation
is certainly not broken.
Hmmm…
OK, next time I nee
On 31 Oct 2016, at 20:25 , Joshua Root wrote:
> Depends on the nature of the breakage, which is not shown above. The only
> dependency is jpeg, which has not changed in some time. My jasper
> installation is certainly not broken.
Hmmm…
OK, next time I need to get more detailed logs. Just don’t
> On Oct 31, 2016, at 1:16 PM, Thibaut Paumard wrote:
>
> Le 31/10/2016 à 17:23, Lawrence Velázquez a écrit :
>>> On Oct 31, 2016, at 12:16 PM, Thibaut Paumard wrote:
>>>
Le 31/10/2016 à 17:01, René J.V. Bertin a écrit :
> On Monday October 31 2016 10:00:05 Ryan Schmidt wrote:
>
>
On 2016-11-1 06:08 , Marko Käning wrote:
Hi Joshua,
On 31 Oct 2016, at 18:04 , Joshua Root wrote:
Why?
because I ran into this:
---
---> Scanning binaries for linking errors
---> Found 5 broken file(s), matching files to ports
---> Found 1 broken port(s), determining rebuild order
---> R
Hi Joshua,
On 31 Oct 2016, at 18:04 , Joshua Root wrote:
> Why?
because I ran into this:
---
$ port dir jasper
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/graphics/jasper
$ sudo port upgrade outdated
---> Computing dependencies for jasper
---> Fetching archive for
Le 31/10/2016 à 17:23, Lawrence Velázquez a écrit :
>> On Oct 31, 2016, at 12:16 PM, Thibaut Paumard wrote:
>>
>>> Le 31/10/2016 à 17:01, René J.V. Bertin a écrit :
On Monday October 31 2016 10:00:05 Ryan Schmidt wrote:
This issue only affects the very small percentage of the MacPor
> On Oct 31, 2016, at 1:04 PM, Lawrence Velázquez wrote:
>
> Now you can check out the new branch and try out the submitter's
> changes. You can also modify the branch as you see fit.
>
> $ git checkout l2dy-curl-ca-bundle-update
Actually, if the rebase is successful, you'll automatically
Why?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
> On Oct 31, 2016, at 11:29 AM, Ryan Schmidt wrote:
>
>> On Oct 5, 2016, at 9:53 PM, Ryan Schmidt wrote:
>>
>> How will this work on GitHub?
>>
>> The user will submit a pull request. How do I test it locally? What if the
>> pull request is incomplete? I know I can tell the user what's wrong,
> On Oct 31, 2016, at 12:16 PM, Thibaut Paumard wrote:
>
>> Le 31/10/2016 à 17:01, René J.V. Bertin a écrit :
>>> On Monday October 31 2016 10:00:05 Ryan Schmidt wrote:
>>>
>>> This issue only affects the very small percentage of the MacPorts user
>>> population (including developers and mainta
Le 31/10/2016 à 17:01, René J.V. Bertin a écrit :
> On Monday October 31 2016 10:00:05 Ryan Schmidt wrote:
>
>> This issue only affects the very small percentage of the MacPorts user
>> population (including developers and maintainers) that clones the git
>> repository. Most users will use the r
On Monday October 31 2016 10:00:05 Ryan Schmidt wrote:
> This issue only affects the very small percentage of the MacPorts user
> population (including developers and maintainers) that clones the git
> repository. Most users will use the rsync server, on which we do generate
> portindexes for e
On Oct 31, 2016, at 11:29 AM, Ryan Schmidt wrote:
> I just want to be told how to get my work done.
+1 for having a 'CheatSheet' of some sort
We did this at $WORK when moving from one system to another, and it's always
been helpful.
> One of the suggestions in this thread was to use the "hub"
> On Oct 5, 2016, at 9:53 PM, Ryan Schmidt wrote:
>
> How will this work on GitHub?
>
> The user will submit a pull request. How do I test it locally? What if the
> pull request is incomplete? I know I can tell the user what's wrong, and they
> can push another commit to the same branch they
> On Oct 31, 2016, at 4:18 AM, René J. V. Bertin wrote:
>
> Clemens Lang wrote:
>
>> If your question is not yet answered, ask on the mailing lists so it can
>> be added.
>
> I may have overlooked this, but does github have any provisions that would
> allow
> the PortIndex files to be genera
> On Oct 31, 2016, at 7:12 AM, René J.V. Bertin wrote:
>
>> On Monday October 31 2016 11:52:28 Rainer Müller wrote:
>>
>> rsync -vt
>> rsync://rsync.macports.org/macports/release/ports/PortIndex_darwin_16_i386/PortIndex*
>> $ports
>
> Thanks for the suggestion, I might do that.
>
> (Are you
On Monday October 31 2016 11:52:28 Rainer Müller wrote:
>Just as with Subversion.
Yeah, I wouldn't expect that the SVC type had any influence on this.
> rsync -vt
> rsync://rsync.macports.org/macports/release/ports/PortIndex_darwin_16_i386/PortIndex*
> $ports
Thanks for the suggestion, I mig
On 2016-10-31 11:41, René J.V. Bertin wrote:
> Pity though, the first-run portindex of a fresh git clone just took about 5
> quarters of an hour on one of my machines (a good 5s/port).
Just as with Subversion.
To speed it up, you could seed it with the latest generated version
from rsync:
rsy
On Monday October 31 2016 10:49:55 Clemens Lang wrote:
Hi,
>Just as with Subversion, the answer is no. Remember that the PortIndex
>is specific to the macOS version you are running, so a server-generated
Ah, of course. I didn't actually know this but indeed port versions could be
specific to OS
On 2016-10-31 10:47, Zero King wrote:
> I just submitted a PR on GitHub and the wiki didn't say how to CC the
> maintainer. Should I use mention like @ryandesign?
Yes, we need to use mentions. GitHub does not provide anything better.
In the general case, you would first need to map the MacPorts h
Hi,
On Mon, Oct 31, 2016 at 10:25:33AM +0100, Davide Liessi wrote:
> I have just noticed in one of my GitHub repositories that in Settings
> -> Options there is a "Merge button" section that lets you
> enable/disable the behaviours of the merge button described in the
> above link.
> Maybe you cou
Hi,
On Mon, Oct 31, 2016 at 10:18:42AM +0100, René J. V. Bertin wrote:
> I may have overlooked this, but does github have any provisions that
> would allow the PortIndex files to be generated on the server and
> served with the actual repo contents? That would probably give a very
> significant r
I just submitted a PR on GitHub and the wiki didn't say how to CC the
maintainer. Should I use mention like @ryandesign?
If mentioning is correct I suggest that we use mention-bot [0] to
automatically mention developers in PRs.
[0] https://github.com/facebook/mention-bot
--
Best regards,
Zer
2016-10-25 15:35 GMT+02:00 Ryan Schmidt :
>
>> On Oct 25, 2016, at 6:54 AM, Rainer Müller wrote:
>>
>> On 2016-10-25 10:36, Ryan Schmidt wrote:
>>>
>>>
>>> On Oct 24, 2016, at 17:57, Clemens Lang wrote:
>>>
> On Tue, Oct 25, 2016 at 12:17:57AM +0200, Marko Käning wrote:
> A description of
Hi Larry,
On 31 Oct 2016, at 05:38 , Lawrence Velázquez wrote:
> Old habits die hard, but from now on do NOT refer to Trac tickets as
> "#12345" in your commit messages; GitHub's website interprets those as
> pull request numbers. Copy and paste the full Trac URL instead.
a post-commit-hook chec
Lawrence Velázquez wrote:
...
> $ git gc --aggressive
FWIW, while theoretically very space-efficient, git's .git directories tend to
grow to considerable size for active repositories. I find it useful to run the
attached script from time to time. It runs the garbage collector, but also
(re)pac
On Friday October 28 2016 21:34:32 Vincent Habchi wrote:
Hi,
>> sqlite> WITH i AS (SELECT id FROM files WHERE path LIKE exp GROUP BY id)
>> SELECT name FROM ports, i WHERE ports.id = i.id;
This works great, and as expected *much* faster than any other method one could
think of currently. Ideal
57 matches
Mail list logo
