On 02/20/2014 10:48 AM, vmonmoonshine@gmail.com wrote:
Hey Zack,
I want to put up Stegotorus up for GSoC this summer. I was wondering if you mind transfering the ownership of your Stegotorus repo:
https://github.com/zackw/stegotorus
To "TheTorProject" on github:
https://github.com/TheTorProject
? (https://github.com/zackw/stegotorus/settings then Transfer)
If you don't feel comfortable, we can fork it as well.
[ Background for tor-dev: I am no longer involved in Stegotorus development. vmon and at least one other person are continuing to work on it; this is currently happening in non-default branches of the copy on my github account. There is also a copy of the repo on gitweb.torproject.org but it has not been updated in quite some time. ]
I discussed this with Roger on IRC yesterday and we came to the conclusion that instead of transferring my Stegotorus repo to the "TheTorProject" organizational account, gitweb.torproject.org/stegotorus.git should be promoted to the master copy. I think right now I am the only person with write access to that copy, and I am not sure what the right procedure is for granting you access. I'm also not good enough at Git to know how to copy all branches of remote A into remote B (short of tedious manual actions and/or shell loops).
I think this would also entail using Tor's Trac for issues instead of Github's issue tracker.
zw
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
In your git config, you can define a pushurl that is different from url. Which effectively means that you can pull from github but push to tor.
So in .git/config, your entry would look something like this (double-check pushurl syntax):
[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = git@github.com:zackw/stegotorus.git fetch = +refs/heads/*:refs/remotes/origin/* pushurl = zackw@gitweb.torproject.org/stegotorus.git [branch "master"] remote = origin merge = refs/heads/master
You could also clone to new directory, change the origin to tor, then push each branch. Unless there are just tons of branches, this should only take a couple of minutes =)
best, Griffin
On 04/01/2014 11:01 AM, Zack Weinberg wrote:
On 02/20/2014 10:48 AM, vmonmoonshine@gmail.com wrote:
Hey Zack,
I want to put up Stegotorus up for GSoC this summer. I was wondering if you mind transfering the ownership of your Stegotorus repo:
https://github.com/zackw/stegotorus
To "TheTorProject" on github:
https://github.com/TheTorProject
? (https://github.com/zackw/stegotorus/settings then Transfer)
If you don't feel comfortable, we can fork it as well.
[ Background for tor-dev: I am no longer involved in Stegotorus development. vmon and at least one other person are continuing to work on it; this is currently happening in non-default branches of the copy on my github account. There is also a copy of the repo on gitweb.torproject.org but it has not been updated in quite some time. ]
I discussed this with Roger on IRC yesterday and we came to the conclusion that instead of transferring my Stegotorus repo to the "TheTorProject" organizational account, gitweb.torproject.org/stegotorus.git should be promoted to the master copy. I think right now I am the only person with write access to that copy, and I am not sure what the right procedure is for granting you access. I'm also not good enough at Git to know how to copy all branches of remote A into remote B (short of tedious manual actions and/or shell loops).
I think this would also entail using Tor's Trac for issues instead of Github's issue tracker.
zw
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 04/01/2014 11:23 AM, Griffin Boyce wrote:
In your git config, you can define a pushurl that is different from url. Which effectively means that you can pull from github but push to tor.
That's not the issue; the issue is that I am unaware of any good way to tell git to pull or push *all* branches that exist in a particular remote. Your example
[remote "origin"] url = git@github.com:zackw/stegotorus.git fetch = +refs/heads/*:refs/remotes/origin/* pushurl = zackw@gitweb.torproject.org/stegotorus.git
would IIUC pull/push only those branches that *already exist* locally. In fact, I don't even know how to get it to *list* all the branches that exist in a remote, whether or not they are tracked in the local copy; when I've had to do this (once before, and never again until I learn a better way) I wound up manually copying and pasting from the branch list on gitweb for the remote in question.
zw
On Tue, Apr 01, 2014 at 12:02:23PM -0400, Zack Weinberg wrote:
On 04/01/2014 11:23 AM, Griffin Boyce wrote:
In your git config, you can define a pushurl that is different from url. Which effectively means that you can pull from github but push to tor.
That's not the issue; the issue is that I am unaware of any good way to tell git to pull or push *all* branches that exist in a particular remote. Your example
[remote "origin"] url = git@github.com:zackw/stegotorus.git fetch = +refs/heads/*:refs/remotes/origin/* pushurl = zackw@gitweb.torproject.org/stegotorus.git
would IIUC pull/push only those branches that *already exist* locally. In fact, I don't even know how to get it to *list* all the branches that exist in a remote, whether or not they are tracked in the local copy; when I've had to do this (once before, and never again until I learn a better way) I wound up manually copying and pasting from the branch list on gitweb for the remote in question.
Is "git ls-remote" what you want there?
On Tue, 01 Apr 2014 12:02:23 +0000, Zack Weinberg wrote: ...
That's not the issue; the issue is that I am unaware of any good way to tell git to pull or push *all* branches that exist in a particular remote. Your example
[remote "origin"] url = git@github.com:zackw/stegotorus.git fetch = +refs/heads/*:refs/remotes/origin/* pushurl = zackw@gitweb.torproject.org/stegotorus.git
would IIUC pull/push only those branches that *already exist* locally.
No, a 'git fetch --prune' will fetch all (local[1]) branches on the remote repo and store them as remotes/origin/*. You can see those branches with 'git branch -a'. The --prune makes a local remotes/origin/* branch disappear when the respective branch in the remote vanished.
In fact, I don't even know how to get it to *list* all the branches that exist in a remote, whether or not they are tracked in the local copy;
There are two kind of 'tracking'. One are the 'tracking branches, i.e. the remotes/origin/* branches that mirror ('track') the state of the remote repo. The other is the branch-specific setting for local branches that link a local branch to a specific branch on the remote.
when I've had to do this (once before, and never again until I learn a better way) I wound up manually copying and pasting from the branch list on gitweb for the remote in question.
If you actually want to push all local branches to a remote:
git push remotename 'refs/heads/*:refs/heads/*'
For that, none of those branches should be the current branch in the remote repository. Apply --force or --prune with care and understanding.
Andreas
[1] 'local branches': Those that aren't remote tracking branches, but show up in 'git branch' without '-a'.
Hey Zack and Roger,
- Why moving: The goal of moving wasn't to disassociate the project from Zack. I wanted to advertise the project link on the volunteer page and I thought, there will be less confusion if it is in the TheTorProject than in Zackw. I asked Arturo to fork Stegotorus in TheTorProject, he said it is simpler if Zackw just moves the repo to TheTorProject.
Arturo is the/an admin of TheTorProject AFAIK and he had made Zack a member of the organization the same day. I think that is enough to move the repo.
- Why github? I think the question of moving Ooni to tor git came up in Iceland and Arturo was happy with keeping it on TheTorProject github account. So I thought the same logic can be applied to Stegotorus. Reasons:
1) It is less painful to move a repo from a github to a github rather than changing servers. 2) github has this feature that you can comment between the lines of commits that tor git doesn't have.
3) Bureaucratically, I seems easier to give pop-up volunteer write access to the github repo rather than to tor git (this was the case for example when I was a student)
- Status of git.torproject.org
If for the sake of having less confusion we want to move stegotorus dev to tor git, I can take care of the move if I'm given access to git.torproject.org:/stegotorus. I think either Roger or Zack needs to make a signed ticket for change of owner/write access assigned to weasel, Sebstian or Erinn.
I have write access to git.torproject.org:/user/vmon/stegtorus (but not to git.torproject.org:/stegotorus) and historically, I was happy with that but that doesn't accomplish the "less confusion" goal.
Thanks everybody, vmon
Zack Weinberg zackw@panix.com writes:
On 02/20/2014 10:48 AM, vmonmoonshine@gmail.com wrote:
Hey Zack,
I want to put up Stegotorus up for GSoC this summer. I was wondering if you mind transfering the ownership of your Stegotorus repo:
https://github.com/zackw/stegotorus
To "TheTorProject" on github:
https://github.com/TheTorProject
? (https://github.com/zackw/stegotorus/settings then Transfer)
If you don't feel comfortable, we can fork it as well.
[ Background for tor-dev: I am no longer involved in Stegotorus development. vmon and at least one other person are continuing to work on it; this is currently happening in non-default branches of the copy on my github account. There is also a copy of the repo on gitweb.torproject.org but it has not been updated in quite some time. ]
I discussed this with Roger on IRC yesterday and we came to the conclusion that instead of transferring my Stegotorus repo to the "TheTorProject" organizational account, gitweb.torproject.org/stegotorus.git should be promoted to the master copy. I think right now I am the only person with write access to that copy, and I am not sure what the right procedure is for granting you access. I'm also not good enough at Git to know how to copy all branches of remote A into remote B (short of tedious manual actions and/or shell loops).
I think this would also entail using Tor's Trac for issues instead of Github's issue tracker.
zw
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Andreas Krey -
Griffin Boyce -
Ian Goldberg -
vmon＠riseup.net -
Zack Weinberg