Re: Working with Git

On 2016-11-04 03: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. > > Do you remember what

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: 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 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

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 >

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: Working with Git

> On Oct 31, 2016, at 12:04 PM, Lawrence Velázquez wrote: > >> 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

Re: Working with Git

> On Nov 1, 2016, at 4:57 AM, Rainer Müller wrote: > >> On 2016-11-01 05:54, Mojca Miklavec wrote: >> >> I'm with Ryan in this case. We don't prevent anyone from using this >> software if they choose to, I just don't see the point of advertising >> software whose maintainer

Re: Working with Git

On 01 Nov 2016, at 09:57 , Rainer Müller wrote: > > I do not see valid reasons not to use hub. +1 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

On 2016-11-01 05:54, Mojca Miklavec wrote: > I can imagine a newbie trying to navigate to the page and thinking > that installation of Homebrew is necessary for making that software > work, just to screw up the rest of MacPorts. An additional problem > might be that whenever users have a problem

Re: Working with Git

Hi Mojca and Ryan, On 01 Nov 2016, at 05:54 , Mojca Miklavec wrote: > I'm with Ryan in this case. We don't prevent anyone from using this > software if they choose to, I just don't see the point of advertising > software whose maintainer decided to go against MP. I am with

Re: Working with Git

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

Re: Working with Git

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.

Re: Working with Git

> 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

Re: Working with Git

> 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

Re: Working with Git

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

Re: Working with Git

> 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

Re: Working with Git

2016-10-08 3:32 GMT+02:00 Lawrence Velázquez : > I think this would be fine, since only a few people are likely to fetch a > pull request branch, and anyone who does just has to be aware that the branch > can be force-updated at any time. I was about to write the same. I

Re: Working with Git

> On Oct 7, 2016, at 6:56 PM, Rainer Müller wrote: > > If you want to replace the commits in a pull request, it will require a > 'git push --force' to the branch of the pull request. I think this would be fine, since only a few people are likely to fetch a pull request

Re: Working with Git

On 2016-10-07 19:00, Brandon Allbery wrote: > On Fri, Oct 7, 2016 at 12:43 PM, Chris Jones > wrote: > > Indeed, I was a little dubious of the suggestions that involve > -force. I suspect there are better ways of working that

Re: Working with Git

On Oct 7, 2016, at 2:20PM, Brandon Allbery wrote: > > On Fri, Oct 7, 2016 at 5:11 PM, Davide Liessi wrote: > On the other hand there is nothing wrong in rewriting history in a > temporary development branch (such as a branch for a pull request) >

Re: Working with Git

2016-10-07 19:34 GMT+02:00 Brandon Allbery : > I only wish other projects actually did this... rewriting history is > regrettably common in some projects. Sigh. Rewriting history in the master branch (or any branch intended to live long) should never be allowed. On the other

Re: Working with Git

> On Oct 7, 2016, at 12:34 PM, Brandon Allbery wrote: > > On Fri, Oct 7, 2016 at 1:31 PM, Marcel Bischoff > wrote: > 'push --force' should *never* be used when working in a team except for > dire emergencies like having cleaned the history of

Re: Working with Git

On Fri, Oct 7, 2016 at 1:31 PM, Marcel Bischoff wrote: > 'push --force' should *never* be used when working in a team except for > dire emergencies like having cleaned the history of accidentally > committed login credentials or the like. > I only wish other projects

Re: Working with Git

On 16/10/07, Brandon Allbery wrote: On Fri, Oct 7, 2016 at 12:43 PM, Chris Jones wrote: On 07/10/16 17:39, Craig Treleaven wrote: On Oct 7, 2016, at 12:16 PM, Sterling Smith wrote: On Oct 7, 2016, at 7:20AM, Chris Jones

Re: Working with Git

On 07/10/16 17:39, Craig Treleaven wrote: On Oct 7, 2016, at 12:16 PM, Sterling Smith wrote: On Oct 7, 2016, at 7:20AM, Chris Jones wrote: My point still stands though, you have to actively try the things you need to do, to get used to

Re: Working with Git

> On Oct 7, 2016, at 12:16 PM, Sterling Smith wrote: > > > On Oct 7, 2016, at 7:20AM, Chris Jones wrote: >> >> My point still stands though, you have to actively try the things you need >> to do, to get used to them. > +1 Yabut, then you

Re: Working with Git

On Oct 7, 2016, at 7:20AM, Chris Jones wrote: > > My point still stands though, you have to actively try the things you need to > do, to get used to them. +1 > ___ > macports-dev mailing list >

Re: Working with Git

> On Oct 7, 2016, at 9:04 AM, Chris Jones wrote: > > Hi, > >>> There will always be problems with the transition to GitHub that can be >>> discussed on the mailing list to find a common solution. Then it can be >>> documented to point people to that if they have the

Re: Working with Git

Hi, There will always be problems with the transition to GitHub that can be discussed on the mailing list to find a common solution. Then it can be documented to point people to that if they have the same problem. Yes. But I want to at least know how to perform the tasks that I currently

Re: Working with Git

> On Oct 7, 2016, at 7:54 AM, Ryan Schmidt wrote: > > >> On Oct 6, 2016, at 12:36 PM, Rainer Müller wrote: >> >> On 2016-10-06 10:22, Ryan Schmidt wrote: >>> On Oct 6, 2016, at 02:33, Sterling Smith >>> wrote: When

Re: Working with Git

On 06/10/16 14:57, Rainer Müller wrote: On 2016-10-06 14:28, Ryan Schmidt wrote: If there are easy ways to rewrite the history of a pull request, by all means, let's suggest the user do that, and provide instructions for how to do so. I have no idea how to do it. You can rewrite the source

Re: Working with Git

> On Oct 6, 2016, at 12:36 PM, Rainer Müller wrote: > > On 2016-10-06 10:22, Ryan Schmidt wrote: >> On Oct 6, 2016, at 02:33, Sterling Smith >> wrote: >>> When is the macports repo on GitHub supposed to appear? >> >> I have no ETA for you yet.

Re: Working with Git

On Oct 6, 2016, at 10:58AM, Rainer Müller wrote: > On 2016-10-06 09:33, Sterling Smith wrote: >> On Oct 5, 2016, at 7:53PM, Ryan Schmidt wrote: >> >>> Suppose a user submits an update to a port. >>> >>> With Subversion, the user would submit a

Re: Working with Git

On 2016-10-06 09:33, Sterling Smith wrote: > On Oct 5, 2016, at 7:53PM, Ryan Schmidt wrote: > >> Suppose a user submits an update to a port. >> >> With Subversion, the user would submit a patch in a Trac ticket. To test it, >> I would download the patch and apply it to

Re: Working with Git

On 2016-10-06 10:22, Ryan Schmidt wrote: > On Oct 6, 2016, at 02:33, Sterling Smith > wrote: >> When is the macports repo on GitHub supposed to appear? > > I have no ETA for you yet. "When it's ready." Part of being ready > includes having documentation about how we'll

Re: Working with Git

On Oct 6, 2016, at 1:22AM, Ryan Schmidt wrote: > On Oct 6, 2016, at 02:33, Sterling Smith wrote: >> >> Ryan, >> >>> On Oct 5, 2016, at 7:53PM, Ryan Schmidt wrote: >>> >>> >>> The user will submit a pull request. How

Re: Working with Git

On 2016-10-06 14:28, Ryan Schmidt wrote: > If there are easy ways to rewrite the history of a pull request, by all > means, let's suggest the user do that, and provide instructions for how to do > so. I have no idea how to do it. You can rewrite the source branch of a pull request in any way

Re: Working with Git

> On Oct 6, 2016, at 7:15 AM, Davide Liessi wrote: > > 2016-10-06 13:15 GMT+02:00 Ryan Schmidt : >> I assumed that in such a case, where the contributor is (or we are) making >> several commits to fix mistakes in a submission, we would use a

Re: Working with Git

2016-10-06 13:15 GMT+02:00 Ryan Schmidt : > I assumed that in such a case, where the contributor is (or we are) making > several commits to fix mistakes in a submission, we would use a "squash > merge" (?) to combine all the changes in the pull request into a single >

Re: Working with Git

On 06/10/16 12:15, Ryan Schmidt wrote: On Oct 6, 2016, at 06:09, Chris Jones wrote: On 06/10/16 11:43, Mojca Miklavec wrote: On 6 October 2016 at 09:39, Chris Jones wrote: How do I take the user's pull request, make additional changes, and commit them to our

Re: Working with Git

On Oct 6, 2016, at 06:09, Chris Jones wrote: > > > >> On 06/10/16 11:43, Mojca Miklavec wrote: >> On 6 October 2016 at 09:39, Chris Jones wrote: How do I take the user's pull request, make additional changes, and commit them to our master? >>> >>> Anyone

Re: Working with Git

On 06/10/16 11:43, Mojca Miklavec wrote: On 6 October 2016 at 09:39, Chris Jones wrote: How do I take the user's pull request, make additional changes, and commit them to our master? Anyone can commit to the branch created by the user for the pull request. So you can just checkout that

Re: Working with Git

On 06/10/16 10:19, Ryan Schmidt wrote: On Oct 6, 2016, at 4:02 AM, Chris Jones wrote: On 06/10/16 10:00, Ryan Schmidt wrote: On Oct 6, 2016, at 3:59 AM, Chris Jones wrote: Hi, The instructions at

Re: Working with Git

> On Oct 6, 2016, at 4:02 AM, Chris Jones wrote: > > > > On 06/10/16 10:00, Ryan Schmidt wrote: >> >>> On Oct 6, 2016, at 3:59 AM, Chris Jones wrote: >>> >>> Hi, >>> >>> The instructions at >>> >>>

Re: Working with Git

On 06/10/16 10:00, Ryan Schmidt wrote: On Oct 6, 2016, at 3:59 AM, Chris Jones wrote: Hi, The instructions at https://trac.macports.org/wiki/WorkingWithGit seem a little out of date w.r.t. forking. It says "To do that, go to ​https://github.com/macports/ports/

Re: Working with Git

> On Oct 6, 2016, at 3:59 AM, Chris Jones wrote: > > Hi, > > The instructions at > > https://trac.macports.org/wiki/WorkingWithGit > > seem a little out of date w.r.t. forking. It says > > "To do that, go to ​https://github.com/macports/ports/ and click the fork >

Re: Working with Git

Hi, The instructions at https://trac.macports.org/wiki/WorkingWithGit seem a little out of date w.r.t. forking. It says "To do that, go to ​https://github.com/macports/ports/ and click the fork button at the top right." but ​https://github.com/macports/ports/ does not exist, it gives a 404

Re: Working with Git

> On Oct 6, 2016, at 03:32, Chris Jones wrote: > > > >> On 06/10/16 09:22, Ryan Schmidt wrote: >>> On Oct 6, 2016, at 02:33, Sterling Smith wrote: >>> >>> Ryan, >>> On Oct 5, 2016, at 7:53PM, Ryan Schmidt

Re: Working with Git

On 06/10/16 09:22, Ryan Schmidt wrote: On Oct 6, 2016, at 02:33, Sterling Smith wrote: Ryan, On Oct 5, 2016, at 7:53PM, Ryan Schmidt wrote: Suppose a user submits an update to a port. With Subversion, the user would submit a patch in a

Re: Working with Git

On Oct 6, 2016, at 02:33, Sterling Smith wrote: > > Ryan, > >> On Oct 5, 2016, at 7:53PM, Ryan Schmidt wrote: >> >> Suppose a user submits an update to a port. >> >> With Subversion, the user would submit a patch in a Trac ticket. To test it,

Re: Working with Git

Hi Ryan, - On 6 Oct, 2016, at 04:53, Ryan Schmidt ryandes...@macports.org wrote: > With Subversion, the user would submit a patch in a Trac ticket. To test it, I > would download the patch and apply it to my local Subversion working copy. If > I > like it, I commit it. If I don't like it, I

Re: Working with Git

> How do I take the user's pull request, make additional changes, and commit them to our master? Anyone can commit to the branch created by the user for the pull request. So you can just checkout that branch yourself, make changes, commit and push them back to the branch, and thus the merge

Re: Working with Git

Ryan, On Oct 5, 2016, at 7:53PM, Ryan Schmidt wrote: > Suppose a user submits an update to a port. > > With Subversion, the user would submit a patch in a Trac ticket. To test it, > I would download the patch and apply it to my local Subversion working copy. > If I

Re: Working with git-svn or hgsubversion (was: Move part of macports infrastructure to GitHub)

On Mar 16, 2014, at 17:18, Rainer Müller wrote: a) No support for svn:ignore property Easy to accomplish, we would just keep the equivalent in .gitignore and .hgignore files in the repository root. The svn:ignore property would still be the authoritative value. As these are barely set at

Re: Working with git-svn or hgsubversion (was: Move part of macports infrastructure to GitHub)

Hi, I'd like to chime in and offer my $.02. I'll try to keep it brief though, because nobody wants to read thousands of large opinionated posts in this thread if it's supposed to go somewhere. I think the popularity gives git the clear advantage over mercurial or any of the other systems.

Re: Working with git-svn or hgsubversion (was: Move part of macportsinfrastructure to GitHub))

Rainer Müller rai...@macports.org writes: On 2014-03-16 19:42, Sean Farley wrote: If MacPorts really wants to switch to distributed version control, then I would suggest Mercurial. I have experimented with using Mercurial for the MacPorts repo and found that the mercurial UI is much, much