plg wrote:
mmoy wrote:
You probably want to use escapeshellarg() to avoid bad surprises.
$temp_path is not a user input. It is something like /path/to/pem/_data/git_clone/2bde29a6dbe17ec08291be6b09386103 where 2bde29a6dbe17ec08291be6b09386103 is a md5(uniqid(rand(), true)). Do you think it could become "../../../" ?
I don't think there's a security hole, but I still feel nervous with any kind of "rm -fr <whatever>" without quoting <whatever> (are you 100% sure it doesn't and will never ever contain space, star or dollar?). Proper quoting doesn't cost anything.
plg wrote:
git cat-file commit HEAD [...] doesn't give me the commit "hash" (which is 72a0ca7d709be32d39a5195bb0dc227276f2a590).
git rev-parse HEAD will give you that.
plg wrote:
I want to fill pem_metadata.txt; with something like:
File automatically created from SVN or Git repository.
URL: https://github.com/umrysh/Piwigo-Twitter-Cards
Revision: 72a0ca7d709be32d39a5195bb0dc227276f2a590 (Thu Jun 26 23:29:06 2014 -0600)
That's sensible, yes.
Offline
From now, piwigo.org extension manager can generate the archive from a Git URL (and just like SVN, with automatic replacement of version number and extension url). I'm going to notify some Git users.
Offline
Hello,
Good news. Great work.
Can we have an option to specify a tag.
I used the tag on the master branch for release.
https://github.com/xbgmsharp/piwigo-ope … p/releases
https://github.com/xbgmsharp/piwigo-videojs/releases
Would be nice if we could have a beta channel from master latest available and production channel from a specific tag as a release.
Offline
xbgmsharp wrote:
Would be nice if we could have a beta channel from master latest available and production channel from a specific tag as a release.
yes but that concernes also svn and maybe also piwigo itself so... good idea but not really planed for now ^^
Offline
xbgmsharp wrote:
Can we have an option to specify a tag.
Did you try to put the tag name in the "branch" field ? as the URL are identical for tags and branches it should work
Offline
Lexiglot is ready to accept Github repository (we wait a few days to identify possible bugs).
--
I wrote a tutorial to explain how to migrate a plugin from piwigo.org Subversion to Github, currently reviewed by Tadjio and soon added in the Wiki (the migration is not mandatory, people will be free to stay on Subversion, and even request new repositories)
--
Things to do on the forum:
- svn:xxxx (old hotlink support) will have to redirect to github after creating the svn revisions/git hashs map
- git:xxxx redirect to github
- issue:xxxx redirect to github
no change for "bug/feature:xxxx" links, Mantis will become readonly but will be kept running for a while
OR we can migrate closed bugs to Github and redirect "bug/feature:xxxx" to Github as well
Problem
How to get the title of an issue (and optionally the message of a git commit) ?
Github has an API, but is limited 5000 requests par hour, if we want to inject issues name in the forum we will certainly have to manage a cache on our server.... or we can just drop that and display only "issue #45"
Offline
You can use a local git repository to get the commit message.
# git log --pretty=short # git log --pretty=format:"%h%x09%an%x09%ad%x09%s"
You can check Gitlog to JSON https://gist.github.com/textarcana/1306223
If refer an issue via is number in the commit message, then you can generate a link to github issue directly.
For the issue title message, you are force to use the API but it is github propitiatory and limited.
The other option is to make your own Github server with Gitlab for example.
Offline
mistic100 wrote:
Problem
How to get the title of an issue (and optionally the message of a git commit) ?
Github has an API, but is limited 5000 requests par hour, if we want to inject issues name in the forum we will certainly have to manage a cache on our server.... or we can just drop that and display only "issue #45"
I can implement the cache mecanism. In case of name change on Github, we have to force refresh. Maybe we should say that cache expires after X hours or days.
Offline
plg wrote:
In the meantime, Git has arrived and Github has become "the place to be" for open source projects. Nowadays, each time I say Piwigo is using SVN I get replies such as "you're a dinosaur, switch to Github: it's a whole new world" ! I don't like the idea to lose control on Piwigo source code repository, but I like even less that Piwigo is not where it should be to attract contributors the easiest way. This is why, after discussions and several months of thinking, I strongly think we have to switch to Git and to Github for source code and for bugtracker.
To keep control on sources, I think a good idea is to install the main repository on piwigo servers and push to github commits with a hook. The official repository is for example git.piwigo.org and backup is github.com/piwigo/piwigo
This way has an another advantage : no problem of cache for internal links !
Offline
but we totally lost the interest of the switch : forks, pull-requests and wide visibility on a social coding network
for me it's "keep our SVN" or "move to Github"
Offline
After Jabber discussion with Nicolas (he gave me tips on Git), having the "official" Git repository on piwigo.org + mirror on Github is mainly a philosophical decision. For me, if we have a mirror on piwigo.org, available in case of "disaster" on Github, it's fine and simpler.
Offline
nicolas wrote:
plg wrote:
In the meantime, Git has arrived and Github has become "the place to be" for open source projects. Nowadays, each time I say Piwigo is using SVN I get replies such as "you're a dinosaur, switch to Github: it's a whole new world" ! I don't like the idea to lose control on Piwigo source code repository, but I like even less that Piwigo is not where it should be to attract contributors the easiest way. This is why, after discussions and several months of thinking, I strongly think we have to switch to Git and to Github for source code and for bugtracker.
To keep control on sources, I think a good idea is to install the main repository on piwigo servers and push to github commits with a hook. The official repository is for example git.piwigo.org and backup is github.com/piwigo/piwigo
This way has an another advantage : no problem of cache for internal links !
There is both samples available for open source project.
For example the kernel main GIT repository is git.kernel.org , and they do have a mirror on Github.
On the other end, a few smaller Open Source project, I know moved it all to Github.
If you want to have full control, you will need something like GitLab and mirror to github to get the social of it.
As usual it the classic fight of internal vs external.
Offline
Question for git/github masters: Can repositories be organized hierarchically ?
Suppose I have 5 piwigo plugins (5 repos), 3 piwigo themes (3 repos), 9 wordpress plugins... Can I "group" the 5 pwg plugins into one group etc ... to avoid a flat list?
In the piwigo organization there are already ~ 4 repositories and it can grow significantly if we add all plugins/themes ...
Thanks
Offline
The question is irrelevant for git :)
But in github, no you can't
--
It has never been planned to move every plugin in Piwigo organization, only the core, the main plugins (maintained by the team), Lexiglot and PEM.
Developpers move their plugins to their own Github account if they want
Offline
Ok. Once I move a plugin/theme to github, what do I have to do?
1. Update scm info in pem ?
2. Give access to translation team in github?
3. Who's updating lexiglot infos?
Offline