Re: Working with Git

> > Now I still seem to have this branch in my local git repo: > > $ git branch > l2dy-curl-ca-bundle-update > * master > > Can I delete it? With, I presume, "git branch -d l2dy-curl-ca-bundle-update"? Yes, you can delete it with the command you show (unless it complains that it is not

Re: Removing "$Id$" lines

On 2 November 2016 at 05:07, David Evans wrote: > > Another reason for not canceling such a build would be to generate a record > of how many ports and which ones are > currently broken. I suspect there are a number that never get reported > because they are old or obscure or just not used >

Re: Poll: should Trac send email notifications when adding or replacing an attachment?

Mojca Miklavec wrote: >> 1- Do you agree there is no need for (this many) notifications concerning >> changes to attachments (= you never missed it)? > > No. I have always been annoyed by the fact that some users (me > included) uploaded an attachment and then I had to tell everyone >

Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

Hi, - On 3 Nov, 2016, at 10:58, René J.V. Bertin rjvber...@gmail.com wrote: > Not to open another can of worms, but just how married are we to trac? Of > course > it's never evident to migrate a web service, but has it never been considered > to > investigate other popular bug trackers

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

On Thursday November 03 2016 11:30:50 Clemens Lang wrote: > We also looked into other bugtrackers, and there was no clear benefit over > Trac > to justify switching. It may just be an impression, but bugzilla comes across as more feature-rich to me. Conversion of existing tickets would be

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

On 2016-11-03 12:38, René J.V. Bertin wrote: > Conversion of existing tickets would be nifty, but I don't think it's > something I'd miss myself. What do you want to discuss then? A bug tracker is for tracking, we will not throw everything away that was reported. Overall, can we just stop this

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

On Thursday November 03 2016 12:42:40 Rainer Müller wrote: > What do you want to discuss then? A bug tracker is for tracking, we will > not throw everything away that was reported. Not converting isn't the same as throwing away. > Overall, can we just stop this discussion, please? We settled to

Re: [MacPorts] #1: foo @1.2: fails to build from source

On 2016-11-03 15:01, MacPorts wrote: > #1: foo @1.2: fails to build from source > -+-- > Reporter: anonymous | Owner: somebody > Type: defect | Status: new > Priority: blocker | Milestone: > Component: component1 |

branch -d and pushing (Was: Working with Git)

Ensure you pull or fetch your merged changes otherwise you'll never be allowed to delete the branch. So if on branch X you have GitHub merge branch Y, you cannot delete Y until you fetch X. If we get lots of branches, you can prune remote tracking easily: git fetch -p (remember: - local

Re: Working with Git

> On Nov 2, 2016, at 11:24 PM, Ryan Schmidt wrote: > > Yes, there are "command line instructions" on the web site, but they > are different from the commands you gave below, which are again > different from other commands suggested in previous threads, so it is >

Properly merging pull requests

Hi, We have recently experienced problems with pull requests showing up as rejected on the web interface rather than merged (while the changes were in fact accepted, possibly with some modifications). I admit my sins. In one case I did a minor modification (squashed commits, removed the "Id"

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

> On Nov 3, 2016, at 8:01 AM, René J.V. Bertin wrote: > > On Thursday November 03 2016 12:42:40 Rainer Müller wrote: > >> Overall, can we just stop this discussion, please? We settled to stay >> with Trac and it is not going to change. > > Really, all your decisions are

How to submit an updated portfile on new system?

Dear all, A new version of Pari has come out, and I will update the portfile soon. However, I haven't found new git compatible workflow documentation anywhere. Should I still do the old-fashioned make a patch and submit in a ticket, or should I fork the repo, modify it, and submit a pull request?

Re: Properly merging pull requests

On Nov 3, 2016, at 8:59AM, Mojca Miklavec wrote: > Hi, > > We have recently experienced problems with pull requests showing up as > rejected on the web interface rather than merged (while the changes > were in fact accepted, possibly with some modifications). > > I admit

Re: How to submit an updated portfile on new system?

> On Nov 3, 2016, at 12:12 PM, Watson Ladd wrote: > > Dear all, > A new version of Pari has come out, and I will update the portfile > soon. However, I haven't found new git compatible workflow > documentation anywhere. Should I still do the old-fashioned make a > patch

Pull Requests for Work in Progress (WIP)

Devs, This thread is meant to continue comments starting with https://github.com/macports/macports-ports/pull/7#issuecomment-258057083 The main question of procedure is: Should the main macports repo be used for proposing review of work in progress via pull requests? If not, what is the

Re: Properly merging pull requests

> On Nov 3, 2016, at 12:19 PM, Sterling Smith wrote: > > The user will not learn if you change it under his/her feet. I think > that you should make line by comments of changes that need to be made > in the files tab of the pull request and ask the pull request >

Re: Properly merging pull requests

On 2016-11-03 16:59, Mojca Miklavec wrote: > Hi, > > We have recently experienced problems with pull requests showing up as > rejected on the web interface rather than merged (while the changes > were in fact accepted, possibly with some modifications). > > I admit my sins. In one case I did a

Re: Pull Requests for Work in Progress (WIP)

On 2016-11-03 17:49, Sterling Smith wrote: > The main question of procedure is: Should the main macports repo be > used for proposing review of work in progress via pull requests? If > not, what is the proposed method? I propose you put your changes on a branch, add the compare URL to a ticket

Re: Properly merging pull requests

> On Nov 3, 2016, at 11:59 AM, Mojca Miklavec wrote: > > We have recently experienced problems with pull requests showing up as > rejected on the web interface rather than merged (while the changes > were in fact accepted, possibly with some modifications). > > I admit my

Re: Properly merging pull requests

> On Nov 3, 2016, at 1:46 PM, Rainer Müller wrote: > > I think the proper way to do it on GitHub would be as follows: > When the pull request author checked the box for "Allow modifications by > maintainers" [1], you can force-push your changes to the pull request > branch,

Re: Pull Requests for Work in Progress (WIP)

On Nov 3, 2016, at 10:47AM, Rainer Müller wrote: > On 2016-11-03 17:49, Sterling Smith wrote: >> The main question of procedure is: Should the main macports repo be >> used for proposing review of work in progress via pull requests? If >> not, what is the proposed method?

Re: Properly merging pull requests

On 2016-11-03 18:57, Lawrence Velázquez wrote: >> On Nov 3, 2016, at 1:46 PM, Rainer Müller wrote: >> >> I think the proper way to do it on GitHub would be as follows: >> When the pull request author checked the box for "Allow modifications by >> maintainers" [1], you can

Re: Properly merging pull requests

> On Nov 3, 2016, at 2:16 PM, Rainer Müller wrote: > > On 2016-11-03 18:57, Lawrence Velázquez wrote: >>> On Nov 3, 2016, at 1:46 PM, Rainer Müller wrote: >>> >>> I think the proper way to do it on GitHub would be as follows: >>> When the pull request

Re: Properly merging pull requests

My 2 cents: * cherry-pick will always change commit hash and github won't see it as the same commit as from original PR * "Closed #10" syntax was designed to close Issues from commit messages. I think if you do "Closes #10" for PR it will close a PR in the way it will look like it was declined *

Re: Properly merging pull requests

> On Nov 3, 2016, at 2:46 PM, Lawrence Velázquez wrote: > > >> On Nov 3, 2016, at 2:16 PM, Rainer Müller wrote: >> >> On 2016-11-03 18:57, Lawrence Velázquez wrote: On Nov 3, 2016, at 1:46 PM, Rainer Müller wrote:

Re: Pull Requests for Work in Progress (WIP)

>>> The main question of procedure is: Should the main macports repo be >>> used for proposing review of work in progress via pull requests? If >>> not, what is the proposed method? >> >> I propose you put your changes on a branch, add the compare URL to a >> ticket or send an email to

Re: Working with Git

> On Nov 3, 2016, at 9:48 PM, Ryan Schmidt wrote: > > I did already run "git branch -D l2dy-curl-ca-bundle-update" when "git > branch -d l2dy-curl-ca-bundle-update" failed because of an error. Do you remember what the error was? The next time it happens could you let me

Re: Working with Git

On Nov 3, 2016, at 21:41, Lawrence Velázquez wrote: >> On Nov 3, 2016, at 9:48 PM, Ryan Schmidt wrote: >> >> I did already run "git branch -D l2dy-curl-ca-bundle-update" when "git >> branch -d l2dy-curl-ca-bundle-update" failed because of an error.

Re: rsync not being kept up to date?

On 2016-11-4 14:41 , Blair Zajac wrote: Seeing some odd things with rsync with this config: root@poppy-mbp:~# grep -v ^# /opt/local/etc/macports/sources.conf | uniq rsync://rsync.macports.org/release/ports/ [default] root@poppy-mbp:~# port -v outdated The following installed ports are

rsync not being kept up to date?

Seeing some odd things with rsync with this config: root@poppy-mbp:~# grep -v ^# /opt/local/etc/macports/sources.conf | uniq rsync://rsync.macports.org/release/ports/ [default] root@poppy-mbp:~# port -v outdated The following installed ports are outdated: curl-ca-bundle

Re: How to keep uncommitted work in a git clone

Religiously use `git status`, and perhaps update your shell prompt to reflect it as well: branch name, unstaged changes, staged changes, etc. Consider looking on Google for prompts that incorporate functions like __git_ps1: GIT_PS1_SHOWDIRTYSTATE="1" GIT_PS1_SHOWUNTRACKEDFILES="1"

Re: rsync not being kept up to date?

On 2016-11-4 14:53 , Blair Zajac wrote: On Nov 3, 2016, at 8:51 PM, Joshua Root wrote: On 2016-11-4 14:41 , Blair Zajac wrote: Seeing some odd things with rsync with this config: root@poppy-mbp:~# grep -v ^# /opt/local/etc/macports/sources.conf | uniq

Re: How to keep uncommitted work in a git clone

On 2016-11-4 12:56 , Ryan Schmidt wrote: With Subversion, I was accustomed to keeping changes in my working copy that I was not ready to commit yet. Git doesn't let me do that. It complains and tells me to git stash and later git stash pop. Well, I tried that. I git stashed, then made

Re: rsync not being kept up to date?

On 2016-11-4 15:02 , Joshua Root wrote: On 2016-11-4 14:53 , Blair Zajac wrote: $ port info mercurial | head -2 mercurial @3.9.2 (devel, python) Sub-ports:mercurial-devel $ port info --index mercurial | head -2 mercurial @4.0 (devel, python) Sub-ports:mercurial-devel

Re: rsync not being kept up to date?

> On Nov 3, 2016, at 11:03 PM, Ryan Schmidt wrote: > >> >> On Nov 3, 2016, at 11:02 PM, Joshua Root wrote: >> >> On 2016-11-4 14:53 , Blair Zajac wrote: >>> On Nov 3, 2016, at 8:51 PM, Joshua Root wrote: On

Re: Working with Git

> On Nov 3, 2016, at 10:36 AM, Lawrence Velázquez wrote: > >> On Nov 2, 2016, at 11:24 PM, Ryan Schmidt wrote: >> >> Yes, there are "command line instructions" on the web site, but they >> are different from the commands you gave below, which are