Re: Working with Git

[Rainer Müller]

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 the error was? The next time it happens could you
> let me know? I could certainly have overlooked something.

After the branch was pushed to the remote master, locally the commits
are only in this branch. You need to do another pull on the master
branch, which will introduce these changes locally, before you can
delete the changes without error.

$ git checkout master
$ git pull --rebase
$ git branch -d l2dy-curl-ca-bundle-update

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

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.
> 
> Do you remember what the error was? The next time it happens could you
> let me know? I could certainly have overlooked something.

I think the complaint was that not all of the changes in the branch could be 
found elsewhere so deleting the branch might lose information. 

I had committed one additional change to the local branch prior to merging it 
to the local master. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Lawrence Velázquez]

> On Nov 3, 2016, at 10:29 PM, Rainer Müller  wrote:
> 
> While Larry's version ensures you will always do a rebase, the version
> from GitHub could fall back to a merge.

Right. My intention is to always avoid merges.

> Assuming the 'git pull' results in a fast-forward, both command
> sequences should be equivalent as far as I can see.

Right.

The problem is that the base branch and head branch will probably have
diverged by the time someone gets around to handling the PR, so "git
pull" will more likely than not end up trying to do a non-ff merge. So
I avoid it entirely.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Lawrence Velázquez]

> 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 know? I could certainly have overlooked something.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Rainer Müller]

On 2016-11-04 02:48, Ryan Schmidt wrote:
> Your instructions and theirs already differ in the way in which the branch 
> changes are obtained.
> 
> You said:
> 
>> To obtain the submitter's changes:
>>
>>  $ git fetch https://github.com/l2dy/macports-ports.git 
>> curl-ca-bundle-update
>>  $ git checkout -b l2dy-curl-ca-bundle-update FETCH_HEAD
>>  $ git rebase master l2dy-curl-ca-bundle-update
>>
>> The first command imports changes from the submitter's
>> "curl-ca-bundle-update" branch. The second command creates a new local
>> branch to match. The third command transplants the submitter's changes
>> onto the top of your master branch. (Rebasing will fail if the
>> submitter's changes don't apply cleanly to the current ports tree. You
>> can just ask them to fix this themselves and push a new branch.)
>>
>> 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
> 
> They say:
> 
>> Step 1: From your project repository, check out a new branch and test the 
>> changes.
>>
>> git checkout -b l2dy-curl-ca-bundle-update master
>> git pull https://github.com/l2dy/macports-ports.git curl-ca-bundle-update

Some things in git can be achieved with different commands. Whether you
first create a branch and then fetch a remote or vice-versa usually does
not matter.

While Larry's version ensures you will always do a rebase, the version
from GitHub could fall back to a merge. Assuming the 'git pull' results
in a fast-forward, both command sequences should be equivalent as far as
I can see.

>>> Thanks, that worked, up until the "git push origin master" command,
>>> which asked me to authenticate, and supplying my username and password
>>> was unsuccessful:
>>>
>>> $ git push origin master
>>> Username for 'https://github.com': ryandesign
>>> Password for 'https://ryandes...@github.com': 
>>> remote: Invalid username or password.
>>> fatal: Authentication failed for 
>>> 'https://github.com/macports/macports-ports.git/'
>>
>> That's curious. What does "git remote -v" print?
> 
> $ git remote -v
> originhttps://github.com/macports/macports-ports.git (fetch)
> originhttps://github.com/macports/macports-ports.git (push)
> 
> Possibly relevant: I do, of course, use two-factor authentication, but I just 
> supplied my password; I was not asked to provide a two-factor auth token. I 
> remember having to follow some instructions to set up GitHub Desktop with 
> some kind of access to allow it to commit, but that was months ago so I 
> couldn't tell you what I did.

With 2FA, you will either have to use a GitHub Access Token for
https://, or use SSH with your public key instead.

https://help.github.com/articles/providing-your-2fa-authentication-code/#through-the-command-line

>> One small addendum: Before "git push origin master", you should run "git
>> pull --rebase" to get any new commits that were pushed by other
>> committers.
> 
> I assume if this was necessary I would have received an error message when I 
> tried to push?

Yes.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

> 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 again
>> different from other commands suggested in previous threads, so it is
>> difficult to know which set of instructions to follow.
> 
> Obviously I think you should follow mine ;)
> 
> The GitHub instructions assume that you're okay with nonlinear history
> (they create merge commits), so we can't really use them. But I found
> them useful for developing my instructions.

Your instructions and theirs already differ in the way in which the branch 
changes are obtained.

You said:

> To obtain the submitter's changes:
> 
>   $ git fetch https://github.com/l2dy/macports-ports.git 
> curl-ca-bundle-update
>   $ git checkout -b l2dy-curl-ca-bundle-update FETCH_HEAD
>   $ git rebase master l2dy-curl-ca-bundle-update
> 
> The first command imports changes from the submitter's
> "curl-ca-bundle-update" branch. The second command creates a new local
> branch to match. The third command transplants the submitter's changes
> onto the top of your master branch. (Rebasing will fail if the
> submitter's changes don't apply cleanly to the current ports tree. You
> can just ask them to fix this themselves and push a new branch.)
> 
> 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

They say:

> Step 1: From your project repository, check out a new branch and test the 
> changes.
> 
> git checkout -b l2dy-curl-ca-bundle-update master
> git pull https://github.com/l2dy/macports-ports.git curl-ca-bundle-update




>> Thanks, that worked, up until the "git push origin master" command,
>> which asked me to authenticate, and supplying my username and password
>> was unsuccessful:
>> 
>> $ git push origin master
>> Username for 'https://github.com': ryandesign
>> Password for 'https://ryandes...@github.com': 
>> remote: Invalid username or password.
>> fatal: Authentication failed for 
>> 'https://github.com/macports/macports-ports.git/'
> 
> That's curious. What does "git remote -v" print?

$ git remote -v
origin  https://github.com/macports/macports-ports.git (fetch)
origin  https://github.com/macports/macports-ports.git (push)

Possibly relevant: I do, of course, use two-factor authentication, but I just 
supplied my password; I was not asked to provide a two-factor auth token. I 
remember having to follow some instructions to set up GitHub Desktop with some 
kind of access to allow it to commit, but that was months ago so I couldn't 
tell you what I did.


>> 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"?
> 
> Yeah, you can delete it. You should NOT use "git branch -D" as Sterling
> suggested because these instructions are designed so that you can always
> fast-forward merge the PR branch into master. If "git branch -d" fails,
> something is not right, and you have to go back and figure out what.

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.


> One small addendum: Before "git push origin master", you should run "git
> pull --rebase" to get any new commits that were pushed by other
> committers.

I assume if this was necessary I would have received an error message when I 
tried to push?


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Lawrence Velázquez]

> 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
> difficult to know which set of instructions to follow.

Obviously I think you should follow mine ;)

The GitHub instructions assume that you're okay with nonlinear history
(they create merge commits), so we can't really use them. But I found
them useful for developing my instructions.

> Thanks, that worked, up until the "git push origin master" command,
> which asked me to authenticate, and supplying my username and password
> was unsuccessful:
> 
> $ git push origin master
> Username for 'https://github.com': ryandesign
> Password for 'https://ryandes...@github.com': 
> remote: Invalid username or password.
> fatal: Authentication failed for 
> 'https://github.com/macports/macports-ports.git/'

That's curious. What does "git remote -v" print?

> 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"?

Yeah, you can delete it. You should NOT use "git branch -D" as Sterling
suggested because these instructions are designed so that you can always
fast-forward merge the PR branch into master. If "git branch -d" fails,
something is not right, and you have to go back and figure out what.

One small addendum: Before "git push origin master", you should run "git
pull --rebase" to get any new commits that were pushed by other
committers.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Sterling Smith]

> 
> 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 merged into master, in which case you might need -D instead of -d).

-Sterling
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

> 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 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 made to initiate the 
>>> pull request, and those new commits will automatically appear in the pull 
>>> request, and I can then merge it if I like it. But what if the user does 
>>> not respond and fix the changes? What if the user makes additional commits 
>>> but they're still not sufficient? How do I take the user's pull request, 
>>> make additional changes, and commit them to our master?
>> 
>> There were several different and sometimes conflicting answers to this 
>> question in this thread. Now that we have converted to git, and I have 
>> received a pull request for one of my ports, I need to know how to test it 
>> locally and then commit it to master. 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.
> 
> Here are some rough instructions. These will have to be refined; let me
> know if you have any problems. I'm writing this in a bit of
> a sleep-deprived fog.
> 
> To the right of the big green "Rebase and merge" button on the PR page,
> you should see a link to view "command line instructions". Those
> instructions are almost what you want, but you'll have to tweak them to
> avoid merge commits.

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 difficult to know which 
set of instructions to follow.


> To obtain the submitter's changes:
> 
>   $ git fetch https://github.com/l2dy/macports-ports.git 
> curl-ca-bundle-update
>   $ git checkout -b l2dy-curl-ca-bundle-update FETCH_HEAD
>   $ git rebase master l2dy-curl-ca-bundle-update
> 
> The first command imports changes from the submitter's
> "curl-ca-bundle-update" branch. The second command creates a new local
> branch to match. The third command transplants the submitter's changes
> onto the top of your master branch. (Rebasing will fail if the
> submitter's changes don't apply cleanly to the current ports tree. You
> can just ask them to fix this themselves and push a new branch.)
> 
> 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
> 
> When you're ready to push the submitter's contributions to master:
> 
>   $ git checkout master
>   $ git merge --ff-only l2dy-curl-ca-bundle-update
>   $ git push origin master

Thanks, that worked, up until the "git push origin master" command, which asked 
me to authenticate, and supplying my username and password was unsuccessful:

$ git push origin master
Username for 'https://github.com': ryandesign
Password for 'https://ryandes...@github.com': 
remote: Invalid username or password.
fatal: Authentication failed for 
'https://github.com/macports/macports-ports.git/'

Instead, I used GitHub Desktop's "Sync" button, which worked. I usually prefer 
to use GitHub Desktop, but it would be nice to be able to push from the command 
line as well.

> The first two commands incorporate the submitter's changes into your
> master branch. The last one pushes to GitHub.

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"?


>> Could someone please update the WorkingWithGit page with the correct 
>> instructions?
> 
> Yes, I will polish up that page this week, as well as the migration FAQ.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Lawrence Velázquez]

> 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 decided to go against MP.
> 
> This argument is just nonsense. I am not going to stop using vim just
> because upstream decided to mention Homebrew (and only Homebrew) in its
> README_mac [1].

+1

The point of the wiki is to help users, not play politics. We do not
have quid pro quo relationships with any upstream developers. As
irritating as the hub devs' attitude may be, the tool they develop may
still be useful to our users, so there's no reason we shouldn't mention
it matter-of-factly and let users decide if it fits their needs. I don't
see this as an advertisement or recommendation.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Marko Käning]

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

[Rainer Müller]

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 with the software and file
> a bug report, they might get an equally annoying answer saying
> "Install Homebrew, I don't support MP". I had a problem with one
> particular project in the past that a typical answer to any bug report
> I filed was "stop using MacPorts, it's obviously broken" when in 90%
> of the cases it was their bug that just showed up when using certain
> newer dependencies or a particular set of configure flags they never
> tested.

You see these kind of messages on many software homepages on the web,
because the Homebrew crowd has to spew it everywhere. Nobody should
think Homebrew is required because of them.

By adding hub to instructions, we never send people to their homepage,
so they will not even see this message.

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

This argument is just nonsense. I am not going to stop using vim just
because upstream decided to mention Homebrew (and only Homebrew) in its
README_mac [1].

I do not see valid reasons not to use hub.

Rainer

[1] https://github.com/vim/vim/blob/master/READMEdir/README_mac.txt
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Marko Käning]

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 you here! Port hub is there for use on MacPorts for anyone who
might find it useful anyways. So, leave it at that and remove the hint on
the wiki page. It doesn’t make sense to do advertisement for someone who’s
not interested in that extra attention.

Greets,
Marko


P.S.: Reading hub’s dev’s comment to the first issue [1] one shouldn’t
even assume open opposition against MacPorts, IMHO. I read there that
the guy wants to support his tool all himself w/o anyone else interfering
and thus he only cares about what he is using, namely HB. I find it
understandable from his point of view if he’s not intending to jointly
develop his code together with the whole Open Source community. The MIT
license allows us to host it and give any interested user access to this
(potentially useful) software. So be it. :)


[1] https://github.com/github/hub/pull/211

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Mojca Miklavec]

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 have twice refused [1] to acknowledge on their 
>> web page that hub can also be installed with MacPorts, I am uncomfortable 
>> referring users to their web page, and I suggest that we do not mention 
>> "hub" in our page.
>
> while that's super-silly of the 'hub' author, I don't think we need to 
> retaliate by not using or recommending the software if it's useful.

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 with the software and file
a bug report, they might get an equally annoying answer saying
"Install Homebrew, I don't support MP". I had a problem with one
particular project in the past that a typical answer to any bug report
I filed was "stop using MacPorts, it's obviously broken" when in 90%
of the cases it was their bug that just showed up when using certain
newer dependencies or a particular set of configure flags they never
tested.

I would understand not accepting a complex patch for the sake of
supporting some legacy system, but not such a strong attitude against
adding one line to the documentation.

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.

Disclaimer: I have no clue how useful the software is, I've never
tested it myself.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Sean Farley]

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.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Lawrence Velázquez]

> 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 end up in
this branch and won't have to check it out yourself.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Lawrence Velázquez]

> 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, and 
>> they can push another commit to the same branch they made to initiate the 
>> pull request, and those new commits will automatically appear in the pull 
>> request, and I can then merge it if I like it. But what if the user does not 
>> respond and fix the changes? What if the user makes additional commits but 
>> they're still not sufficient? How do I take the user's pull request, make 
>> additional changes, and commit them to our master?
> 
> There were several different and sometimes conflicting answers to this 
> question in this thread. Now that we have converted to git, and I have 
> received a pull request for one of my ports, I need to know how to test it 
> locally and then commit it to master. 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.

Here are some rough instructions. These will have to be refined; let me
know if you have any problems. I'm writing this in a bit of
a sleep-deprived fog.

To the right of the big green "Rebase and merge" button on the PR page,
you should see a link to view "command line instructions". Those
instructions are almost what you want, but you'll have to tweak them to
avoid merge commits.

To obtain the submitter's changes:

$ git fetch https://github.com/l2dy/macports-ports.git 
curl-ca-bundle-update
$ git checkout -b l2dy-curl-ca-bundle-update FETCH_HEAD
$ git rebase master l2dy-curl-ca-bundle-update

The first command imports changes from the submitter's
"curl-ca-bundle-update" branch. The second command creates a new local
branch to match. The third command transplants the submitter's changes
onto the top of your master branch. (Rebasing will fail if the
submitter's changes don't apply cleanly to the current ports tree. You
can just ask them to fix this themselves and push a new branch.)

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

When you're ready to push the submitter's contributions to master:

$ git checkout master
$ git merge --ff-only l2dy-curl-ca-bundle-update
$ git push origin master

The first two commands incorporate the submitter's changes into your
master branch. The last one pushes to GitHub.

> Could someone please update the WorkingWithGit page with the correct 
> instructions?

Yes, I will polish up that page this week, as well as the migration FAQ.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Daniel J. Luke]

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" wrapper around 
> git. Based on the fact that their homepage only mentions how to install hub 
> with Homebrew, and that they have twice refused [1] to acknowledge on their 
> web page that hub can also be installed with MacPorts, I am uncomfortable 
> referring users to their web page, and I suggest that we do not mention "hub" 
> in our page.

while that's super-silly of the 'hub' author, I don't think we need to 
retaliate by not using or recommending the software if it's useful.

-- 
Daniel J. Luke



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

> 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 made to initiate the pull 
> request, and those new commits will automatically appear in the pull request, 
> and I can then merge it if I like it. But what if the user does not respond 
> and fix the changes? What if the user makes additional commits but they're 
> still not sufficient? How do I take the user's pull request, make additional 
> changes, and commit them to our master?

There were several different and sometimes conflicting answers to this question 
in this thread. Now that we have converted to git, and I have received a pull 
request for one of my ports, I need to know how to test it locally and then 
commit it to master. 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. Could someone please update the WorkingWithGit page with the correct 
instructions?

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 have twice refused [1] to acknowledge on their web page 
that hub can also be installed with MacPorts, I am uncomfortable referring 
users to their web page, and I suggest that we do not mention "hub" in our page.


[1] https://github.com/github/hub/pulls?utf8=✓&q=is%3Apr%20macports

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Davide Liessi]

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 would also like to propose that pull requests should always be
merged using the "Rebase and merge" option, in order to keep the
master branch as linear as possible (see
https://help.github.com/articles/merging-a-pull-request/ and
https://help.github.com/articles/about-pull-request-merges/#rebase-and-merge-your-pull-request-commits).

Davide
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Lawrence Velázquez]

> 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 branch, and anyone who does just has to be aware that the branch can be 
force-updated at any time.

vq
Sent from my iPhone
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Rainer Müller]

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 should avoid
> the need for that.
> 
> 
> --force only comes into it when you are rewriting history (i.e. merging
> existing commits that were already sent upstream). Best is to not do
> this; work in a branch, combine commits after, and cherrypick those to
> *another* clean branch (or diff the first branch to get all changes as
> one patch, and apply it in the new branch to get a single commit).

It would not be helpful to keep all commits from a pull request that
took multiple iterations, that just adds clutter in the history and in
the blame output.

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. There is no way
around it, except closing the pull request and submitting it as a new
pull request, which breaks the connection to the previous discussion.

> Or just accept multiple commits instead of trying to pretend to be a neat
> freak after hosting a wild party.

If the pull request just had a few fixups after the initial commit, that
would be solved by squash merging everything into a single commit on the
merge.

However, a squash merge should not be used when multiple logical
separated commits were submitted in a pull request (for example separate
whitespace changes).

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Sterling Smith]

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)
> before merging to a long living branch.
> 
> as long as it never got pushed upstream, yes. If it did, and someone else 
> based local changes on it, they've got A Problem.

One online thread I read pointed out that rebasing can be a good thing, but 
that it can lead to needing to force push a branch on which others may have 
made local changes.  But that thread said that the solution is not less 
rebasing, but actually more, because if a person has set to always rebase when 
pulling, then their local changes will naturally be put on top of the now 
rebased force pushed remote.

There was some merit to Brandon's other comment: " Or just accept multiple 
commits instead of trying to pretend to be a neat freak after hosting a wild 
party."

-Sterling

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Brandon Allbery]

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)
> before merging to a long living branch.
>

as long as it never got pushed upstream, yes. If it did, and someone else
based local changes on it, they've got A Problem.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Davide Liessi]

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 hand there is nothing wrong in rewriting history in a
temporary development branch (such as a branch for a pull request)
before merging to a long living branch.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

> 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 accidentally
> committed login credentials or the like.
> 
> I only wish other projects actually did this... rewriting history is 
> regrettably common in some projects. Sigh.

GitHub provides a facility for admins to specify which branches should not 
allow force. We will configure that properly.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Brandon Allbery]

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 actually did this... rewriting history is
regrettably common in some projects. Sigh.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Marcel Bischoff]

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  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 hear things like “use —force when you need”, except then
you hear “—force can really screw things


 up”.  I’m a little gunshy of that screw-things-up part!

Indeed, I was a little dubious of the suggestions that involve -force. I
suspect there are better ways of working that should avoid the need for
that.



--force only comes into it when you are rewriting history (i.e. merging
existing commits that were already sent upstream). Best is to not do this;
work in a branch, combine commits after, and cherrypick those to *another*
clean branch (or diff the first branch to get all changes as one patch, and
apply it in the new branch to get a single commit). Or just accept multiple
commits instead of trying to pretend to be a neat freak after hosting a
wild party.


'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. It completely rewrites the
remote history of the repository, invalidating all local clones
immediately and leaving a mess for all collaborators. Git is designed to
work with branches whenever possible and 'merge' or 'merge --squash'
them when you're finished.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Brandon Allbery]

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  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 hear things like “use —force when you need”, except then
>> you hear “—force can really screw things
>>
>  up”.  I’m a little gunshy of that screw-things-up part!
>
> Indeed, I was a little dubious of the suggestions that involve -force. I
> suspect there are better ways of working that should avoid the need for
> that.


--force only comes into it when you are rewriting history (i.e. merging
existing commits that were already sent upstream). Best is to not do this;
work in a branch, combine commits after, and cherrypick those to *another*
clean branch (or diff the first branch to get all changes as one patch, and
apply it in the new branch to get a single commit). Or just accept multiple
commits instead of trying to pretend to be a neat freak after hosting a
wild party.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

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 them.

+1


Yabut, then you hear things like “use —force when you need”, except then you 
hear “—force can really screw things

 up”.  I’m a little gunshy of that screw-things-up part!

Indeed, I was a little dubious of the suggestions that involve -force. I 
suspect there are better ways of working that should avoid the need for 
that.


Chris



Craig



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Craig Treleaven]

> 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 hear things like “use —force when you need”, except then you 
hear “—force can really screw things up”.  I’m a little gunshy of that 
screw-things-up part!

Craig


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Sterling Smith]

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
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

On 07/10/16 15:16, Ryan Schmidt wrote:



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 same problem.


Yes. But I want to at least know how to perform the tasks that I currently 
perform with Trac and Subversion once we move to GitHub. I currently do not 
feel that I understand how to do that, and worry that I and other contributors 
who do not know Git very well will no longer be able to contribute effectively 
once we switch.


My experience with moving from subversion to git is you can read about it as 
much as you want, but there is no substitute for just starting to try and use 
it. It takes a little time to get used to, but once you do you will not go back 
to svn.

So whilst I understand you want to try and work everything out up front, before 
hand, in practice I think you have to expect a bit of a learning curve for 
everyone at first, and basically just dive in and make the change.


I have used Git and GitHub for years; I joined GitHub in 2010. Doesn't mean I 
know how to do anything more than clone and commit.


My point still stands though, you have to actively try the things you 
need to do, to get used to them.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

> 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 same problem.
>> 
>> Yes. But I want to at least know how to perform the tasks that I currently 
>> perform with Trac and Subversion once we move to GitHub. I currently do not 
>> feel that I understand how to do that, and worry that I and other 
>> contributors who do not know Git very well will no longer be able to 
>> contribute effectively once we switch.
> 
> My experience with moving from subversion to git is you can read about it as 
> much as you want, but there is no substitute for just starting to try and use 
> it. It takes a little time to get used to, but once you do you will not go 
> back to svn.
> 
> So whilst I understand you want to try and work everything out up front, 
> before hand, in practice I think you have to expect a bit of a learning curve 
> for everyone at first, and basically just dive in and make the change.

I have used Git and GitHub for years; I joined GitHub in 2010. Doesn't mean I 
know how to do anything more than clone and commit.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

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 
perform with Trac and Subversion once we move to GitHub. I currently do not 
feel that I understand how to do that, and worry that I and other contributors 
who do not know Git very well will no longer be able to contribute effectively 
once we switch.


My experience with moving from subversion to git is you can read about 
it as much as you want, but there is no substitute for just starting to 
try and use it. It takes a little time to get used to, but once you do 
you will not go back to svn.


So whilst I understand you want to try and work everything out up front, 
before hand, in practice I think you have to expect a bit of a learning 
curve for everyone at first, and basically just dive in and make the change.


Chris
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[mf2k]

> 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 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 perform the tasks we
>>> need to perform on GitHub, so people who know how to do that should
>>> definitely contribute to the documentation, and people should ask
>>> questions about things that aren't explained in the documentation.
>> 
>> While I agree we need some basic rules, I do not think we need to make
>> the instructions too complex. Nobody is going to read them anymore when
>> they get too long.
>> 
>> We should have an idea how we want to work, but we cannot anticipate
>> everything. MacPorts has always formed its policies and workflows by
>> learning how maintainers do their work. I think we should continue the
>> process that way.
>> 
>> 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 
> perform with Trac and Subversion once we move to GitHub. I currently do not 
> feel that I understand how to do that, and worry that I and other 
> contributors who do not know Git very well will no longer be able to 
> contribute effectively once we switch.

That’s my concern as well. I consider myself a gitwit and I want simple 
instructions to commit changes to a Portfile made by myself and given a 
user/maintainer submitted patch. I do sometimes modify a submitted patch, but I 
can live with committing it exactly and then committing my changes afterwards. 
I don’t need to know the proper git way to do that right now. I’m assuming I 
will get more familiar with it as time goes on. 


Cheers!
Frank

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Russell Jones]

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 branch of a pull request in any way you want.
You can use 'git commit --amend' to add something to the last commit, or
you can do a 'git rebase -i' to change specific commits further down in
the history in any way you want.

After doing such changes to the branch history, git would reject a
normal push to the branch as it not only appends new commits at the top
of the branch. Therefore this will require a 'git push --force' to make
the branch look exactly like the reworked version.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Though "git push --force" is potentially quite dangerous 
https://about.gitlab.com/2014/11/26/keeping-your-code-protected/


Russell
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

> 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. "When it's ready." Part of being ready
>> includes having documentation about how we'll perform the tasks we
>> need to perform on GitHub, so people who know how to do that should
>> definitely contribute to the documentation, and people should ask
>> questions about things that aren't explained in the documentation.
> 
> While I agree we need some basic rules, I do not think we need to make
> the instructions too complex. Nobody is going to read them anymore when
> they get too long.
> 
> We should have an idea how we want to work, but we cannot anticipate
> everything. MacPorts has always formed its policies and workflows by
> learning how maintainers do their work. I think we should continue the
> process that way.
> 
> 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 
perform with Trac and Subversion once we move to GitHub. I currently do not 
feel that I understand how to do that, and worry that I and other contributors 
who do not know Git very well will no longer be able to contribute effectively 
once we switch.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Sterling Smith]

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 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 give feedback to the 
>>> user in the ticket, or I edit the Portfile further and commit it, then tell 
>>> the user in the ticket what changes I made.
>>> 
>>> How will this work on GitHub?
>>> 
>>> The user will submit a pull request. How do I test it locally?
>> You test their changes by checking out their branch on your system.  Most 
>> likely they are on their own fork, and you will need to add their fork as a 
>> new remote
>> 
>> git remote add  
>> 
>> before checking out their branch by issuing
>> 
>> git checkout   # Note that this can fail if more than one remote has 
>> the same branch name (such as master...), and there is a more verbose way to 
>> indicate from where to check out the branch
> 
> You will not need a new remote for this as GitHub will store a copy of
> the branch submitted in the pull request in our repository.
> 
> Check the GitHub documentation here:
> 
> https://help.github.com/articles/checking-out-pull-requests-locally/#modifying-an-inactive-pull-request-locally
Thanks, I learned something new.

> 
> 
> You can also use the hub [1] wrapper around git
Yet another thing I have learned.
> to make such things
> easier. This tool implies all repository URLs will point to GitHub. For
> example, the command
>  hub remote add raimue/ports
> would add a new remote named "raimue" with the URL for this repository
> on GitHub.
> 
> Even better, many commands will just accept references to commits or
> pull requests on GitHub. For example, you can directly switch to a local
> checkout of a pull request with a single command:
>  hub checkout https://github.com/macports/ports/pull/42
> Also works similarly with 'hub cherry-pick' or 'hub am'.
Perhaps the MacPorts recommendation (via wiki documentation) should be to use 
hub instead of git, if it is so great.

-Sterling

> 
> Although I do not like their proposal to alias git to hub, as I like to
> keep control what extensions I use with git. I prefer to explicitly call
> hub when I want to work with GitHub.
> 
> Rainer
> 
> [1] https://hub.github.com/ ; 'sudo port install hub'
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Rainer Müller]

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 my local Subversion working copy. 
>> If I like it, I commit it. If I don't like it, I give feedback to the user 
>> in the ticket, or I edit the Portfile further and commit it, then tell the 
>> user in the ticket what changes I made.
>>
>> How will this work on GitHub?
>>
>> The user will submit a pull request. How do I test it locally?
> You test their changes by checking out their branch on your system.  Most 
> likely they are on their own fork, and you will need to add their fork as a 
> new remote
> 
> git remote add  
> 
> before checking out their branch by issuing
> 
> git checkout   # Note that this can fail if more than one remote has 
> the same branch name (such as master...), and there is a more verbose way to 
> indicate from where to check out the branch

You will not need a new remote for this as GitHub will store a copy of
the branch submitted in the pull request in our repository.

Check the GitHub documentation here:

https://help.github.com/articles/checking-out-pull-requests-locally/#modifying-an-inactive-pull-request-locally


You can also use the hub [1] wrapper around git to make such things
easier. This tool implies all repository URLs will point to GitHub. For
example, the command
  hub remote add raimue/ports
would add a new remote named "raimue" with the URL for this repository
on GitHub.

Even better, many commands will just accept references to commits or
pull requests on GitHub. For example, you can directly switch to a local
checkout of a pull request with a single command:
  hub checkout https://github.com/macports/ports/pull/42
Also works similarly with 'hub cherry-pick' or 'hub am'.

Although I do not like their proposal to alias git to hub, as I like to
keep control what extensions I use with git. I prefer to explicitly call
hub when I want to work with GitHub.

Rainer

[1] https://hub.github.com/ ; 'sudo port install hub'
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Rainer Müller]

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 perform the tasks we
> need to perform on GitHub, so people who know how to do that should
> definitely contribute to the documentation, and people should ask
> questions about things that aren't explained in the documentation.

While I agree we need some basic rules, I do not think we need to make
the instructions too complex. Nobody is going to read them anymore when
they get too long.

We should have an idea how we want to work, but we cannot anticipate
everything. MacPorts has always formed its policies and workflows by
learning how maintainers do their work. I think we should continue the
process that way.

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.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Sterling Smith]

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 do I test it locally?
>> You test their changes by checking out their branch on your system.  Most 
>> likely they are on their own fork, and you will need to add their fork as a 
>> new remote
>> 
>> git remote add  
>> 
>> before checking out their branch by issuing
>> 
>> git checkout   # Note that this can fail if more than one remote has 
>> the same branch name (such as master...), and there is a more verbose way to 
>> indicate from where to check out the branch
> 
> Can you or someone please add this to the WorkingWithGit wiki page?

I see that using other branches through `git checkout` is not yet present in 
the wiki.  I will try to add something along the lines of what I wrote here 
about trying out other people's changes.

> 
> Sounds like the list of remotes is going to get unwieldy. How should one keep 
> it sane?
You can delete remotes as easily as adding them.  

More recently, GitHub has provided finer grained control over pushing to 
specific branches in a given repo, and the MacPorts committers could choose to 
restrict pushes to their own major development branches while still allowing 
all users to create new branches on the main MacPorts repo.  This might 
significantly lessen the number of remotes.  However, I doubt that is the path 
that is desirable, because it allows too many people opportunity to screw up 
someone else's work (accidentally or on purpose).
> 
> 
> I did not know that was possible. Who is able to commit to a fork? I presume 
> only the person who made the fork, and committers of the original repo.
Permissions on each fork can be set by the owner of the fork.  The starting 
permissions are those you indicate.
> If that's true, then how would a second non-committer contribute to and 
> improve the first non-committer's fork / pull request?
> 
The second non-committer would commit to their own branch and push to their own 
fork, then file a pull request from their fork to the 1st non-committer fork.  
An example was
https://github.com/QuadmasterXLII/matplotlib/pull/1
It no longer appears as a clean pull request of a few commits because I ended 
up rebasing my branch to be able to merge it into the main repo, as there was a 
takeover of the pull request as
https://github.com/matplotlib/matplotlib/pull/6988

> 
>> and then you might ask another committer to look over your work and make the 
>> final merge to master, or if you are above review, you could just merge your 
>> work yourself.
> 
> For major changes yes some review process might be nice. We'll need to work 
> that out after we move. We don't have a formal review process for that kind 
> of thing today. 
Presumably whoever hits the merge button (or merges at the command line) 
reviewed the code.  GitHub has also recently formalized pull request reviews.
> 
> 
>>> -Ryan
>> 
>> 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 perform the tasks we need to perform on 
> GitHub, so people who know how to do that should definitely contribute to the 
> documentation, and people should ask questions about things that aren't 
> explained in the documentation. 
OK.  I went looking for it, but couldn't find it.  Hopefully lack of 
documentation is not the show-stopper for converting to git, as the best way 
for developers to realize what is missing is by using git and GitHub.

-Sterling

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Rainer Müller]

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 you want.
You can use 'git commit --amend' to add something to the last commit, or
you can do a 'git rebase -i' to change specific commits further down in
the history in any way you want.

After doing such changes to the branch history, git would reject a
normal push to the branch as it not only appends new commits at the top
of the branch. Therefore this will require a 'git push --force' to make
the branch look exactly like the reworked version.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

> 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 "squash 
>> merge" (?) to combine all the changes in the pull request into a single 
>> commit on master. The GitHub web interface provides an option for this. If 
>> we want to rebase instead of merge (?) we would need to write up a procedure 
>> for how that's accomplished.
> 
> May I suggest instead that we avoid squashing *all* changes of a pull
> request in a *single* commit?
> 
> Of course, if there are many commits that address a single bug, I
> think it is good to squash them into one single commit.
> What I would oppose is having a single commit that upgrades the
> version, restructures the Portfile and addresses bugs, all at the same
> time, unless the changes really are entangled.
> 
> In case of complicated history of commits in a pull request (because
> it was complicated already in the beginning, or as a result of pull
> request revision), I think that the contributor should fix the history
> of the branch in order to get one logical change per commit (usually
> it is just a matter of reordering and squashing commits using the
> interactive rebase, i.e., `git rebase -i`).
> Another way would be to require contributors to address only one issue
> (be it upgrading, fixing a single bug, ...) per pull request: in that
> case I would have no objections to squashing the whole pull request in
> a single commit.
> 
> One way or the other, I think the "one logical change per commit" rule
> of thumb is very important in order to really have a useful and tidy
> history.

Yes. My point is that we often get contributions in Trac that are wrong in some 
way. The user wants to upgrade the version, and they forget to remove the 
revision line. Or the project has moved to github, but they've manually changed 
master_sites, homepage, distname, livecheck, etc. in the portfile instead of 
using the github portgroup. I don't want a series of commits on master that 
reflect the history of correcting those mistakes--mistakes which originated 
with that pull request. We currently don't have that in Subversion because we 
fix those problems before committing.

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.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Davide Liessi]

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 
> commit on master. The GitHub web interface provides an option for this. If we 
> want to rebase instead of merge (?) we would need to write up a procedure for 
> how that's accomplished.

May I suggest instead that we avoid squashing *all* changes of a pull
request in a *single* commit?

Of course, if there are many commits that address a single bug, I
think it is good to squash them into one single commit.
What I would oppose is having a single commit that upgrades the
version, restructures the Portfile and addresses bugs, all at the same
time, unless the changes really are entangled.

In case of complicated history of commits in a pull request (because
it was complicated already in the beginning, or as a result of pull
request revision), I think that the contributor should fix the history
of the branch in order to get one logical change per commit (usually
it is just a matter of reordering and squashing commits using the
interactive rebase, i.e., `git rebase -i`).
Another way would be to require contributors to address only one issue
(be it upgrading, fixing a single bug, ...) per pull request: in that
case I would have no objections to squashing the whole pull request in
a single commit.

One way or the other, I think the "one logical change per commit" rule
of thumb is very important in order to really have a useful and tidy
history.

Best wishes.
Davide
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

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 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 request.


Interesting, thank you, I didn't know (or think of) that.

My next question was going to be: what happens when user submits a
pull request that needs quite a bit of editing? Say that the user
first changes all the whitespacing together with content changes and
potentially does some other mistakes like increasing epoch for no good
reason etc. Of course he can then make another commit that changes
that back, but we would end up with super weird history for no good
reason unless we take the liberty to modify the commits (heavily)
before accepting them.


I guess one option would be to reject the request, providing information on 
why, and leave it to the user to fix the issues and resubmit a new request. If 
they need to they can rebase/revert their local checkout back to before their 
changes, to remove the bad commits from the history.


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 commit on master. The GitHub 
web interface provides an option for this. If we want to rebase instead of merge (?) we 
would need to write up a procedure for how that's accomplished.



yeah, that is probably better. Simpler for the user at least.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

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 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 request.
>> 
>> Interesting, thank you, I didn't know (or think of) that.
>> 
>> My next question was going to be: what happens when user submits a
>> pull request that needs quite a bit of editing? Say that the user
>> first changes all the whitespacing together with content changes and
>> potentially does some other mistakes like increasing epoch for no good
>> reason etc. Of course he can then make another commit that changes
>> that back, but we would end up with super weird history for no good
>> reason unless we take the liberty to modify the commits (heavily)
>> before accepting them.
> 
> I guess one option would be to reject the request, providing information on 
> why, and leave it to the user to fix the issues and resubmit a new request. 
> If they need to they can rebase/revert their local checkout back to before 
> their changes, to remove the bad commits from the history.

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 commit on 
master. The GitHub web interface provides an option for this. If we want to 
rebase instead of merge (?) we would need to write up a procedure for how 
that's accomplished. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

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 branch yourself, make changes, commit and push
them back to the branch, and thus the merge request.


Interesting, thank you, I didn't know (or think of) that.

My next question was going to be: what happens when user submits a
pull request that needs quite a bit of editing? Say that the user
first changes all the whitespacing together with content changes and
potentially does some other mistakes like increasing epoch for no good
reason etc. Of course he can then make another commit that changes
that back, but we would end up with super weird history for no good
reason unless we take the liberty to modify the commits (heavily)
before accepting them.


I guess one option would be to reject the request, providing information 
on why, and leave it to the user to fix the issues and resubmit a new 
request. If they need to they can rebase/revert their local checkout 
back to before their changes, to remove the bad commits from the history.




Mojca


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Mojca Miklavec]

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 branch yourself, make changes, commit and push
> them back to the branch, and thus the merge request.

Interesting, thank you, I didn't know (or think of) that.

My next question was going to be: what happens when user submits a
pull request that needs quite a bit of editing? Say that the user
first changes all the whitespacing together with content changes and
potentially does some other mistakes like increasing epoch for no good
reason etc. Of course he can then make another commit that changes
that back, but we would end up with super weird history for no good
reason unless we take the liberty to modify the commits (heavily)
before accepting them.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

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

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 error...


Not out of date; rather, anticipating repositories which will exist in the 
future.


So where do I go right now, to fork things ?

git clone g...@github.com:macports/ports.git # or
git clone https://github.com/macports/ports.git # if SSH does not work on your 
network

Also give similar errors...


You can't; we haven't converted to git yet.


My mistake. I thought we had SVN mirroring in place.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

> 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
>>> 
>>> 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 
>>> error...
>> 
>> Not out of date; rather, anticipating repositories which will exist in the 
>> future.
> 
> So where do I go right now, to fork things ?
> 
> git clone g...@github.com:macports/ports.git # or
> git clone https://github.com/macports/ports.git # if SSH does not work on 
> your network
> 
> Also give similar errors...

You can't; we haven't converted to git yet.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

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/ and click the fork button at 
the top right."

but ​https://github.com/macports/ports/ does not exist, it gives a 404 error...


Not out of date; rather, anticipating repositories which will exist in the 
future.


So where do I go right now, to fork things ?

git clone g...@github.com:macports/ports.git # or
git clone https://github.com/macports/ports.git # if SSH does not work 
on your network


Also give similar errors...

Chris
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

> 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 
> button at the top right."
> 
> but ​https://github.com/macports/ports/ does not exist, it gives a 404 
> error...

Not out of date; rather, anticipating repositories which will exist in the 
future.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

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 
error...


Chris

On 06/10/16 09:44, Ryan Schmidt wrote:




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  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 
like it, I commit it. If I don't like it, I give feedback to the user in the 
ticket, or I edit the Portfile further and commit it, then tell the user in the 
ticket what changes I made.

How will this work on GitHub?

The user will submit a pull request. How do I test it locally?

You test their changes by checking out their branch on your system.  Most 
likely they are on their own fork, and you will need to add their fork as a new 
remote

git remote add  

before checking out their branch by issuing

git checkout   # Note that this can fail if more than one remote has 
the same branch name (such as master...), and there is a more verbose way to indicate 
from where to check out the branch


Can you or someone please add this to the WorkingWithGit wiki page?

Sounds like the list of remotes is going to get unwieldy. How should one keep 
it sane?


Just through good management. Each MR needs its own branch. That branch can 
either be on a remote repo, or (if the project allows) a branch on the main 
repo. Once a MR is merged, the source branch can be deleted.


When you say "MR", you mean merge request, aka pull request in GitHub 
terminology?

I understand that a pull request should begin its life in a branch created 
specifically for this purpose, in a fork of the repo. That's up to the person 
submitting the PR to get right.

I'm talking about how I, as a MacPorts committer, will review, accept and 
otherwise deal with PRs sent by non-committers.



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 made to 
initiate the pull request, and those new commits will automatically appear in 
the pull request, and I can then merge it if I like it.

Yep.

But what if the user does not respond and fix the changes? What if the user 
makes additional commits but they're still not sufficient? How do I take the 
user's pull request, make additional changes, and commit them to our master?

Instead of committing to master, you should commit to the user's fork/branch to 
add your changes to the pull request,


I did not know that was possible. Who is able to commit to a fork? I presume 
only the person who made the fork, and committers of the original repo. If 
that's true, then how would a second non-committer contribute to and improve 
the first non-committer's fork / pull request?


It depends how the owner of the fork has set up their repo.


I did not know there was any way to "set up" a fork. What is there to do, other than 
click the "fork" button on the GitHub web site?


It gets simpler (in my view) if you take merge requests from a temporary branch 
on the main repo, as then anyone who is able to create MRs can commit to other 
ones.


Committers can certainly create branches in the official MacPorts repositories. 
With Subversion, committers generally just commit to trunk. We haven't yet 
defined any policies for whether to continue that on GitHub or to encourage the 
use of branches more.

But we also accept contributions from non-committers. I want to make sure I 
understand how that will work.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

Hi,

On 06/10/16 09:44, Ryan Schmidt wrote:




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  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 
like it, I commit it. If I don't like it, I give feedback to the user in the 
ticket, or I edit the Portfile further and commit it, then tell the user in the 
ticket what changes I made.

How will this work on GitHub?

The user will submit a pull request. How do I test it locally?

You test their changes by checking out their branch on your system.  Most 
likely they are on their own fork, and you will need to add their fork as a new 
remote

git remote add  

before checking out their branch by issuing

git checkout   # Note that this can fail if more than one remote has 
the same branch name (such as master...), and there is a more verbose way to indicate 
from where to check out the branch


Can you or someone please add this to the WorkingWithGit wiki page?

Sounds like the list of remotes is going to get unwieldy. How should one keep 
it sane?


Just through good management. Each MR needs its own branch. That branch can 
either be on a remote repo, or (if the project allows) a branch on the main 
repo. Once a MR is merged, the source branch can be deleted.


When you say "MR", you mean merge request, aka pull request in GitHub 
terminology?


Sorry, yes. I am more familiar with gitlab than git hum, and thats the 
term there.




I understand that a pull request should begin its life in a branch created 
specifically for this purpose, in a fork of the repo.


Yes, it should be in a branch, but that branch does not *have* to be in 
a fork. You could allow that branch to be part of the main repo. It can 
be in a fork, and forks are useful for developers for their own uses, 
but when they are ready to push something back to the main repo, they 
could make a branch in that repo. In my view things get a bit easier for 
those reviewing and accepting the pull request in this way, as they 
don't have to know about the existance of the users fork.


 That's up to the person submitting the PR to get right.


I'm talking about how I, as a MacPorts committer, will review, accept and 
otherwise deal with PRs sent by non-committers.



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 made to 
initiate the pull request, and those new commits will automatically appear in 
the pull request, and I can then merge it if I like it.

Yep.

But what if the user does not respond and fix the changes? What if the user 
makes additional commits but they're still not sufficient? How do I take the 
user's pull request, make additional changes, and commit them to our master?

Instead of committing to master, you should commit to the user's fork/branch to 
add your changes to the pull request,


I did not know that was possible. Who is able to commit to a fork? I presume 
only the person who made the fork, and committers of the original repo. If 
that's true, then how would a second non-committer contribute to and improve 
the first non-committer's fork / pull request?


It depends how the owner of the fork has set up their repo.


I did not know there was any way to "set up" a fork. What is there to do, other than 
click the "fork" button on the GitHub web site?


Again, I am more familiar with gitlab than github, but there once I have 
forked a repo, there are settings I can access for that fork, to 
configure things like access. I would be surprised if github did not 
have something similar.


Chris



It gets simpler (in my view) if you take merge requests from a temporary branch 
on the main repo, as then anyone who is able to create MRs can commit to other 
ones.


Committers can certainly create branches in the official MacPorts repositories. 
With Subversion, committers generally just commit to trunk. We haven't yet 
defined any policies for whether to continue that on GitHub or to encourage the 
use of branches more.

But we also accept contributions from non-committers. I want to make sure I 
understand how that will work.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

> 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  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 like it, I commit it. If I don't like it, I give feedback to 
 the user in the ticket, or I edit the Portfile further and commit it, then 
 tell the user in the ticket what changes I made.
 
 How will this work on GitHub?
 
 The user will submit a pull request. How do I test it locally?
>>> You test their changes by checking out their branch on your system.  Most 
>>> likely they are on their own fork, and you will need to add their fork as a 
>>> new remote
>>> 
>>> git remote add  
>>> 
>>> before checking out their branch by issuing
>>> 
>>> git checkout   # Note that this can fail if more than one remote 
>>> has the same branch name (such as master...), and there is a more verbose 
>>> way to indicate from where to check out the branch
>> 
>> Can you or someone please add this to the WorkingWithGit wiki page?
>> 
>> Sounds like the list of remotes is going to get unwieldy. How should one 
>> keep it sane?
> 
> Just through good management. Each MR needs its own branch. That branch can 
> either be on a remote repo, or (if the project allows) a branch on the main 
> repo. Once a MR is merged, the source branch can be deleted.

When you say "MR", you mean merge request, aka pull request in GitHub 
terminology?

I understand that a pull request should begin its life in a branch created 
specifically for this purpose, in a fork of the repo. That's up to the person 
submitting the PR to get right. 

I'm talking about how I, as a MacPorts committer, will review, accept and 
otherwise deal with PRs sent by non-committers. 


 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 made to 
 initiate the pull request, and those new commits will automatically appear 
 in the pull request, and I can then merge it if I like it.
>>> Yep.
 But what if the user does not respond and fix the changes? What if the 
 user makes additional commits but they're still not sufficient? How do I 
 take the user's pull request, make additional changes, and commit them to 
 our master?
>>> Instead of committing to master, you should commit to the user's 
>>> fork/branch to add your changes to the pull request,
>> 
>> I did not know that was possible. Who is able to commit to a fork? I presume 
>> only the person who made the fork, and committers of the original repo. If 
>> that's true, then how would a second non-committer contribute to and improve 
>> the first non-committer's fork / pull request?
> 
> It depends how the owner of the fork has set up their repo.

I did not know there was any way to "set up" a fork. What is there to do, other 
than click the "fork" button on the GitHub web site?

> It gets simpler (in my view) if you take merge requests from a temporary 
> branch on the main repo, as then anyone who is able to create MRs can commit 
> to other ones.

Committers can certainly create branches in the official MacPorts repositories. 
With Subversion, committers generally just commit to trunk. We haven't yet 
defined any policies for whether to continue that on GitHub or to encourage the 
use of branches more.

But we also accept contributions from non-committers. I want to make sure I 
understand how that will work. 


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

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 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 give feedback to the user in the 
ticket, or I edit the Portfile further and commit it, then tell the user in the 
ticket what changes I made.

How will this work on GitHub?

The user will submit a pull request. How do I test it locally?

You test their changes by checking out their branch on your system.  Most 
likely they are on their own fork, and you will need to add their fork as a new 
remote

git remote add  

before checking out their branch by issuing

git checkout   # Note that this can fail if more than one remote has 
the same branch name (such as master...), and there is a more verbose way to indicate 
from where to check out the branch


Can you or someone please add this to the WorkingWithGit wiki page?

Sounds like the list of remotes is going to get unwieldy. How should one keep 
it sane?


Just through good management. Each MR needs its own branch. That branch 
can either be on a remote repo, or (if the project allows) a branch on 
the main repo. Once a MR is merged, the source branch can be deleted.





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 made to 
initiate the pull request, and those new commits will automatically appear in 
the pull request, and I can then merge it if I like it.

Yep.

But what if the user does not respond and fix the changes? What if the user 
makes additional commits but they're still not sufficient? How do I take the 
user's pull request, make additional changes, and commit them to our master?

Instead of committing to master, you should commit to the user's fork/branch to 
add your changes to the pull request,


I did not know that was possible. Who is able to commit to a fork? I presume 
only the person who made the fork, and committers of the original repo. If 
that's true, then how would a second non-committer contribute to and improve 
the first non-committer's fork / pull request?


It depends how the owner of the fork has set up their repo. It gets 
simpler (in my view) if you take merge requests from a temporary branch 
on the main repo, as then anyone who is able to create MRs can commit to 
other ones.






and then you might ask another committer to look over your work and make the 
final merge to master, or if you are above review, you could just merge your 
work yourself.


For major changes yes some review process might be nice. We'll need to work 
that out after we move. We don't have a formal review process for that kind of 
thing today.


Clemens, in your repository here, you committed something I had previously 
committed in a fork, but had not submitted a pull request for:

https://github.com/neverpanic/macports-svn2git-rules/commit/bfeed37956f72bf996865e414a375128186d1adf

The GitHub interface says "ryandesign committed with neverpanic". How did you 
cause that notation to appear, and is that something we should be using in our MacPorts 
git workflow?

git keeps track of both author and committer (also sign-off?).  When you commit some 
change for the first time, then you are added as author and committer.  If a person 
cherry-picks or uses rebase to incorporate some commit into a branch, then the committer 
is changed to the person that applied the cherry pick or rebase.  If the author and 
committer are different, then GitHub detects that and presents the two parts as you have 
seen as "ryandesign committed with never panic".


Ok, so we don't need to do anything special; this happens automatically.



-Ryan


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 perform the tasks we need to perform on GitHub, so 
people who know how to do that should definitely contribute to the documentation, and 
people should ask questions about things that aren't explained in the documentation.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Ryan Schmidt]

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, 
>> 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 give feedback to the user 
>> in the ticket, or I edit the Portfile further and commit it, then tell the 
>> user in the ticket what changes I made.
>> 
>> How will this work on GitHub?
>> 
>> The user will submit a pull request. How do I test it locally?
> You test their changes by checking out their branch on your system.  Most 
> likely they are on their own fork, and you will need to add their fork as a 
> new remote
> 
> git remote add  
> 
> before checking out their branch by issuing
> 
> git checkout   # Note that this can fail if more than one remote has 
> the same branch name (such as master...), and there is a more verbose way to 
> indicate from where to check out the branch

Can you or someone please add this to the WorkingWithGit wiki page?

Sounds like the list of remotes is going to get unwieldy. How should one keep 
it sane?


>> 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 made to 
>> initiate the pull request, and those new commits will automatically appear 
>> in the pull request, and I can then merge it if I like it.
> Yep.
>> But what if the user does not respond and fix the changes? What if the user 
>> makes additional commits but they're still not sufficient? How do I take the 
>> user's pull request, make additional changes, and commit them to our master?
> Instead of committing to master, you should commit to the user's fork/branch 
> to add your changes to the pull request,

I did not know that was possible. Who is able to commit to a fork? I presume 
only the person who made the fork, and committers of the original repo. If 
that's true, then how would a second non-committer contribute to and improve 
the first non-committer's fork / pull request?


> and then you might ask another committer to look over your work and make the 
> final merge to master, or if you are above review, you could just merge your 
> work yourself.

For major changes yes some review process might be nice. We'll need to work 
that out after we move. We don't have a formal review process for that kind of 
thing today. 

>> Clemens, in your repository here, you committed something I had previously 
>> committed in a fork, but had not submitted a pull request for:
>> 
>> https://github.com/neverpanic/macports-svn2git-rules/commit/bfeed37956f72bf996865e414a375128186d1adf
>> 
>> The GitHub interface says "ryandesign committed with neverpanic". How did 
>> you cause that notation to appear, and is that something we should be using 
>> in our MacPorts git workflow?
> git keeps track of both author and committer (also sign-off?).  When you 
> commit some change for the first time, then you are added as author and 
> committer.  If a person cherry-picks or uses rebase to incorporate some 
> commit into a branch, then the committer is changed to the person that 
> applied the cherry pick or rebase.  If the author and committer are 
> different, then GitHub detects that and presents the two parts as you have 
> seen as "ryandesign committed with never panic".

Ok, so we don't need to do anything special; this happens automatically. 


>> -Ryan
> 
> 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 perform the tasks we need to perform on 
GitHub, so people who know how to do that should definitely contribute to the 
documentation, and people should ask questions about things that aren't 
explained in the documentation. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Clemens Lang]

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 give feedback to the user in the
> ticket, or I edit the Portfile further and commit it, then tell the user in 
> the
> ticket what changes I made.
> 
> How will this work on GitHub?

You add the pull request as a remote, fetch the changes, check them out in a
branch and test locally. If you like them, merge/cherry-pick/rebase them into 
the
master and push. This automatically closes the pull request.

Alternatively, you can start amending the changes locally by adding new commits 
on
top, or editing existing commits. If you like, you can push those back to the 
pull
request and submit them using GitHub's interface, but there's really not that 
much
difference between committing them directly and clicking the merge submit in the
pull request UI.

If a user updates his pull request that works the same way as a normal update 
from
git would: You fetch the changes and update your local copy; see our existing 
docs
on working with git.


> Clemens, in your repository here, you committed something I had previously
> committed in a fork, but had not submitted a pull request for:
> 
> https://github.com/neverpanic/macports-svn2git-rules/commit/bfeed37956f72bf996865e414a375128186d1adf
> 
> The GitHub interface says "ryandesign committed with neverpanic". How did you
> cause that notation to appear, and is that something we should be using in our
> MacPorts git workflow?

I added your repository as remote and used git cherry-pick $your_commit_id. I 
then
edited your change using git commit --amend and git rebase --interactive and
pushed. The Author field of the commit was not modified, but the Committer field
was changed to me, which is why you see "ryandesign committed with neverpanic".

HTH,
-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

> 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 request.


Chris
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Sterling Smith]

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 like it, I commit it. If I don't like it, I give feedback to the user in 
> the ticket, or I edit the Portfile further and commit it, then tell the user 
> in the ticket what changes I made.
> 
> How will this work on GitHub?
> 
> The user will submit a pull request. How do I test it locally?
You test their changes by checking out their branch on your system.  Most 
likely they are on their own fork, and you will need to add their fork as a new 
remote

git remote add  

before checking out their branch by issuing

git checkout   # Note that this can fail if more than one remote has 
the same branch name (such as master...), and there is a more verbose way to 
indicate from where to check out the branch

> 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 made to 
> initiate the pull request, and those new commits will automatically appear in 
> the pull request, and I can then merge it if I like it.
Yep.
> But what if the user does not respond and fix the changes? What if the user 
> makes additional commits but they're still not sufficient? How do I take the 
> user's pull request, make additional changes, and commit them to our master?
Instead of committing to master, you should commit to the user's fork/branch to 
add your changes to the pull request, and then you might ask another committer 
to look over your work and make the final merge to master, or if you are above 
review, you could just merge your work yourself.
> 
> Clemens, in your repository here, you committed something I had previously 
> committed in a fork, but had not submitted a pull request for:
> 
> https://github.com/neverpanic/macports-svn2git-rules/commit/bfeed37956f72bf996865e414a375128186d1adf
> 
> The GitHub interface says "ryandesign committed with neverpanic". How did you 
> cause that notation to appear, and is that something we should be using in 
> our MacPorts git workflow?
git keeps track of both author and committer (also sign-off?).  When you commit 
some change for the first time, then you are added as author and committer.  If 
a person cherry-picks or uses rebase to incorporate some commit into a branch, 
then the committer is changed to the person that applied the cherry pick or 
rebase.  If the author and committer are different, then GitHub detects that 
and presents the two parts as you have seen as "ryandesign committed with never 
panic".
> 
> -Ryan

When is the macports repo on GitHub supposed to appear?

-Sterling
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ryan Schmidt]

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
>  all in the ports tree, that should not be a problem.

Agreed. To Clemens’ point that these could get out of sync, a pre-commit hook 
on the Subversion server could ensure that they are not out of sync (or else 
block the commit, with a message telling the user how to make them sync).


> b) No support for svn:keywords property
> 
>  Most notably we are using svn:keywords to replace the $Id$ string in
>  every Portfile. I think this string is of limited use and we could do
>  without it.
> 
>  See also this ticket for a detailed discussion of the problem:
>  http://trac.macports.org/ticket/38902
> 
>  (Following the comments in the ticket,  it's not even an issue with
>  newer versions of git-svn any more. What about hgsubversion?)

Agreed, we could get rid of the $Id$ line and stop using svn:keywords.


> c) No support for svn:eol-style property
> 
>  Do we need that at all, anyway? I don't think anybody is editing this
>  on Windows, so I doubt we would ever see a file with CRLF line
>  endings.

We want our text files to have only LF line endings—not CRLF line endings, and 
certainly not a mix of LF and CRLF line endings. I don’t know if anyone uses an 
editor that defaults to other than LF line ending styles, but I don’t want to 
find out about it after a lot of bad commits have already been made. 
svn:eol-style is enforced on the client side. To prevent problems caused by 
clients that don’t do this, we could write a pre-commit hook to enforce this in 
the repository. A hook to enforce that the required properties are set was 
already planned for a long time:

https://trac.macports.org/ticket/12594

The idea to write a hook to prevent non-respected properties is here:

https://trac.macports.org/ticket/38902



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Sean Farley]

Clemens Lang  writes:

> 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. Also, recent versions of OS X ship with git in the command 
> line tools, but it doesn't seem hg is in that package. Since one possible 
> advantage of git would be to efficiently sync the ports tree using git, I 
> think that gives git a clear advantage.

Sigh. The popularity of git has always surprised me since Mercurial
accomplishes the same thing and is much, much safer to use. 

I have been with many other teams that switched to git because of a few
(loud) proponents and never once was it worth the headache of git. As a
team, they have all suffered from someone tripping over one of
fast-forward merging, rebasing, or figuring out what 'git checkout'
really does.

Mercurial on the other hand guarantees safety of history rewriting
(through changeset evolution) and has the better scaling over git,
thanks to Facebook's contributions:

https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/

... but I digress. This has already turned into a git vs. hg flame war
and I did not want to go down that path.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with git-svn or hgsubversion

[Rainer Müller]

On 2014-03-16 23:57, Clemens Lang wrote:
>> I propose we change to our policies to make it possible to work
>> with any tool locally, giving developers the choice to work with
>> the tool they like the most, be it svn, git-svn, hgsubversion,
>> bzr-svn, ...
> 
> While I like the idea of that, I'm not sure it's really going to work
> well in the long run. We already have a number of people committing
> changes from mercurial or git-svn and especially the keywords keep
> getting mixed up on those.

That's why I started this thread to find out and discuss what we have to
change to make it work.

>> 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 all in the ports
>> tree, that should not be a problem.
> 
> I'd like to make a point against doing that. Keeping ignores in
> multiple files will only cause them to get out-of-sync. Some of the
> ignores in svn:ignore will sooner or later be committed as .gitignore
> files (to the SVN repository!), by oversight or on purpose. That's
> going to become a mess I'd like to avoid.

Of course I meant to store the .gitignore and .hgignore files in the
Subversion repository. In fact, we already have a .gitignore file in
trunk/. As I said, svn:ignore would still be authoritative and the other
files should only be generated.

.gitignore can be generated using 'git svn show-ignore > .gitignore'. As
an alternative, it would also be possible to use many small files in
each directory instead using 'git svn create-ignore'.

For .hgignore, Sean provided the command 'hg svn genignore' in another
reply.

The main starting point of this discussion was the ports tree, where
svn:ignore does not change often, so I don't see the additional
generation step as a problem.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Sean Farley]

Rainer Müller  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 more
>> consistent than git coming from Subversion.
>
> I definitely don't want to start a discussion whether git or Mercurial
> is the better tool, but they both other integration to Subversion with
> git-svn [1] and hgsubversion [2].
>
> I propose we change to our policies to make it possible to work with any
> tool locally, giving developers the choice to work with the tool they
> like the most, be it svn, git-svn, hgsubversion, bzr-svn, ...

That's fine with me. Just a note that bazaar is pretty much dead, if I
understand correctly.

> For example, both LLVM [3] and WebKit [4] keep Subversion as their main
> repository, but also encourage contributors to use git to prepare patches.
>
> In a perfect world, that would already be possible out of the box, for
> example working against our existing Git mirror of the MacPorts
> repository [5]. Unfortunately, these tools have some shortcomings that
> make working with our current ports tree impossible. The problems are
> the missing support for Subversion properties.

I've worked a lot on integrating missing features into hgsubversion and
will respond below.

> 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
>   all in the ports tree, that should not be a problem.

This is generated with 'hg svn genignore'.

> b) No support for svn:keywords property
>
>   Most notably we are using svn:keywords to replace the $Id$ string in
>   every Portfile. I think this string is of limited use and we could do
>   without it.
>
>   See also this ticket for a detailed discussion of the problem:
>   http://trac.macports.org/ticket/38902
>
>   (Following the comments in the ticket,  it's not even an issue with
>   newer versions of git-svn any more. What about hgsubversion?)

This is orthogonal to hgsubversion and is supported by keyword extension
(bundled with Mercurial for ages).

> c) No support for svn:eol-style property
>
>   Do we need that at all, anyway? I don't think anybody is editing this
>   on Windows, so I doubt we would ever see a file with CRLF line
>   endings.

Also bundled with Mercurial for ages.

> d) Optional, nice to have: mapping usernames to real names
>
>   Both git and Mercurial usually display real names with email
>   addresses instead of plain usernames. A file with that mapping can be
>   used, but has to be kept in sync (or can be generated from the wiki).
>
>   At the moment our git mirror uses "@macports.org@" as
>   committer. This correctly identifies the person, but is not very nice.

This has been supported in hgsubversion since the beginning. It just
needs an authormap which I provide in my Mercurial repo at
smf.io/macports.

Similarly, I've maintained mergeinfo, tags, branches, etc.

> e) Optional, nice to have: split base, doc, www, and ports tree
>
>   With the current git mirror everyone interested in the ports tree is
>   also required to fetch the trees for base/, doc/ and doc-new/, and
>   www/.
>
>   This is not about disk space as a git clone with full history
>   actually takes less space than a Subversion working copy, but a
>   separate repository might be easier to handle, especially when you
>   can just add that to sources.conf. Note we already have contrib/ and
>   users/ as separate repositories.

Not a bad idea.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Clemens Lang]

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. Also, recent versions of OS X ship with git in the command 
line tools, but it doesn't seem hg is in that package. Since one possible 
advantage of git would be to efficiently sync the ports tree using git, I think 
that gives git a clear advantage.

> I propose we change to our policies to make it possible to work with any
> tool locally, giving developers the choice to work with the tool they
> like the most, be it svn, git-svn, hgsubversion, bzr-svn, ...

While I like the idea of that, I'm not sure it's really going to work well in 
the long run. We already have a number of people committing changes from 
mercurial or git-svn and especially the keywords keep getting mixed up on those.

> 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
>   all in the ports tree, that should not be a problem.

I'd like to make a point against doing that. Keeping ignores in multiple files 
will only cause them to get out-of-sync. Some of the ignores in svn:ignore will 
sooner or later be committed as .gitignore files (to the SVN repository!), by 
oversight or on purpose. That's going to become a mess I'd like to avoid.

> b) No support for svn:keywords property
> c) No support for svn:eol-style property

I agree we should drop those completely.

> d) Optional, nice to have: mapping usernames to real names

If we'd move to a different VCS completely, we'd only have to get this right 
once. I don't think getting all the integration right in every detail is a task 
we have the manpower to do continuously.

> e) Optional, nice to have: split base, doc, www, and ports tree

Definitely a good idea IMO.

In the end I think the easiest way to get this done – if at all – is to choose 
a single blessed system and have everybody bite the bullet and learn it. In my 
opinion, that system should be git, just because it's becoming the de-facto 
standard tool for the job. I know others might be better in some aspects, and 
some of the internals of git are a little bit weird, but this was about making 
contribution easier for more people – and git gets that done.


In regard to using Github:

I don't think Github's issue tracker scales well to our needs. The port field 
is a must for a MacPorts issue tracker, IMO. I also think it's formatting 
capabilities are sub-par: try reproducing http://trac.macports.org/ticket/41466 
in a Github issue. We could certainly move the wiki, but if we're keeping trac 
anyway I don't see the point.

I've worked with Gerrit and Github and pull requests are definitely the easiest 
I've seen. However, they lack just in the same way as their tickets do. Please 
show me where Github has the same features now provided by 
http://trac.macports.org/report and http://trac.macports.org/query. I don't 
want MacPorts to be flooded with pull requests to a point where maintainers can 
no longer find those specific to their ports. Maybe we can instead improve 
documentation to a point where contributing is really easy – instead of going 
to Github and clicking "pull request" after git push, we should give people 
clear and precise steps to get their patch into $issuetracker.

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev