On Mon, May 9, 2011 at 20:12, Colomban Wendling
lists@herbesfolles.org wrote:
Le 09/05/2011 19:35, Jiří Techet a écrit :
I'd say that VCS migration and bug tracking system migration should be
done separately and independently. Migration of the bug tracker is a
lot of work while migration
On 05/10/11 14:05, Jiří Techet wrote:
I really have nothing specific against GitHub (actually from what I
have seen I like it better than Gitorious) and I have no evidence they
are planning to change their policy. What I wanted to say is that the
selection of the right VCS hosting site is much
Hey,
Sorry for the response delay, but not I answer:
Le 28/04/2011 03:36, Matthew Brush a écrit :
Summary from previous thread:
The people in the thread who do not want to switch to Git, or those who
don't seem to care either way, are those who have commit access to
Subversion on
Le 28/04/2011 23:43, Jiří Techet a écrit :
On Thu, Apr 28, 2011 at 07:01, Matthew Brush mbr...@codebrainz.ca wrote:
On 04/27/11 21:01, Lex Trotman wrote:
- No need to maintain changelog and authors files
Changelog and authors are still needed for tarballs, but maybe they
can be automated?
Le 03/05/2011 00:43, Jiří Techet a écrit :
On Mon, May 2, 2011 at 16:33, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
Am 02.05.2011 00:18, schrieb Jiří Techet:
Yes, I would also prefer if there was a proper and complete git switch
(it would greatly save maintainer's work IMO)
On 5/9/2011 9:27 AM, Colomban Wendling wrote:
I second the Git switch, so 1/4 (and I guess Frank will second too).
Just note I have no experience using GitHub (or even no real with
Gitorious) or working with pull requests and co, but I'd be happy to git
it a try -- and probably adopt it.
On Mon, May 9, 2011 at 16:16, Colomban Wendling
lists@herbesfolles.org wrote:
Cons from the previous thread:
- It's more social
I have some cons against social networks, but there are pros here, so...
- Not plain enough (I guess too Web 2.0/feature-full/cluttered)
I don't personally
2011/5/8 Enrico Tröger enrico.troe...@uvena.de:
Hi Enrico,
in principle you have to put something like
git push --mirror your_github_repository
under .git/hooks/post-receive (in the local geany repository). When
creating the github repository, you should create a new public/private
key pair and
On Mon, 9 May 2011 19:44:15 +0200, Jiří wrote:
2011/5/8 Enrico Tröger enrico.troe...@uvena.de:
Hi Enrico,
in principle you have to put something like
git push --mirror your_github_repository
under .git/hooks/post-receive (in the local geany repository). When
creating the github repository, you
Le 09/05/2011 19:35, Jiří Techet a écrit :
On Mon, May 9, 2011 at 16:16, Colomban Wendling
lists@herbesfolles.org wrote:
- Effort required to move the project
That's the big part!
Not that bad if you move the repository only to GitHub - see below.
Right.
- No need to maintain
But the point on the possible future of GitHub is important IMO. if we
have no guarantee for the long-term viability -- and when I read you I
read I'd not be really surprised if it happened --, do we really want
to use this? I mean, if we need to switch to another official repo next
year
On 05/09/11 11:12, Colomban Wendling wrote:
Le 09/05/2011 19:35, Jiří Techet a écrit :
I'd say that VCS migration and bug tracking system migration should be
done separately and independently. Migration of the bug tracker is a
lot of work while migration to git is quite easy. I'd also be
Le 10/05/2011 00:43, Lex Trotman a écrit :
But the point on the possible future of GitHub is important IMO. if we
have no guarantee for the long-term viability -- and when I read you I
read I'd not be really surprised if it happened --, do we really want
to use this? I mean, if we need to
Le 10/05/2011 01:34, Matthew Brush a écrit :
On 05/09/11 11:12, Colomban Wendling wrote:
Le 09/05/2011 19:35, Jiří Techet a écrit :
I'd say that VCS migration and bug tracking system migration should be
done separately and independently. Migration of the bug tracker is a
lot of work while
On 05/09/11 17:16, Colomban Wendling wrote:
Maybe, need to check but might not be that painful (BTW, don't GitHub
offers a SF BT import feature? :D)
It wouldn't surprise me if it does have such a feature (or script
available somewhere). Alternatively, I could probably hack something
On Sun, 1 May 2011 17:53:21 +0200, Jiří wrote:
2011/4/30 Enrico Tröger enrico.troe...@uvena.de:
On Sat, 30 Apr 2011 19:34:51 +1000, Lex wrote:
2011/4/30 Enrico Tröger enrico.troe...@uvena.de:
On Thu, 28 Apr 2011 23:43:39 +0200, Jiří wrote:
One more idea - even if the core developers don't
Am 02.05.2011 03:33, schrieb Matthew Brush:
[1] https://github.com/blog/626-announcing-svn-support
[2] https://github.com/blog/644-subversion-write-support
Ah, that was what I was asking for in my other mail. However, it seems
not very ideal for SVN users.
Best regards.
On Mon, May 2, 2011 at 16:33, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
Am 02.05.2011 00:18, schrieb Jiří Techet:
Yes, I would also prefer if there was a proper and complete git switch
(it would greatly save maintainer's work IMO) but I haven't seen much
enthusiasm from the
On 05/02/11 15:43, Jiří Techet wrote:
So direct question: Enrico, Nick, what's your opinion on the git
switch? As Matthew said, it seems that it's possible to access a
github repository both via svn and git so both the current workflow
and git-based workflow should be possible. Of course I'll
Am 30.04.2011 11:52, schrieb Enrico Tröger:
But we have git.geany.org.
The mirror GIT repositories are synced from SVN and the sync is
triggered by commit mails.
So, we do have a kind of our own commit hook, from SVN as well as from
GIT. I just don't know what I should do in the hook :).
On Sun, May 1, 2011 at 23:46, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
Am 30.04.2011 11:48, schrieb Matthew Brush:
I think the more important part is, are the core developers going to
accept pull/merge requests on github/gitorious, apply commits/patches from
there, etc.? If
On Thu, 28 Apr 2011 23:43:39 +0200, Jiří wrote:
One more idea - even if the core developers don't want the switch, at
least the current geany git repository could be set up to push changes
to github so people who want to use git have an up-to-date mirror from
which they can clone and create
2011/4/30 Enrico Tröger enrico.troe...@uvena.de:
On Thu, 28 Apr 2011 23:43:39 +0200, Jiří wrote:
One more idea - even if the core developers don't want the switch, at
least the current geany git repository could be set up to push changes
to github so people who want to use git have an
On 04/30/11 02:07, Enrico Tröger wrote:
On Thu, 28 Apr 2011 23:43:39 +0200, Jiří wrote:
One more idea - even if the core developers don't want the switch, at
least the current geany git repository could be set up to push changes
to github so people who want to use git have an up-to-date
On Sat, 30 Apr 2011 19:34:51 +1000, Lex wrote:
2011/4/30 Enrico Tröger enrico.troe...@uvena.de:
On Thu, 28 Apr 2011 23:43:39 +0200, Jiří wrote:
One more idea - even if the core developers don't want the switch, at
least the current geany git repository could be set up to push
changes to github
Hi Matthew,
you couldn't express my feelings better.
On Thu, Apr 28, 2011 at 07:01, Matthew Brush mbr...@codebrainz.ca wrote:
On 04/27/11 21:01, Lex Trotman wrote:
- No need to maintain changelog and authors files
Changelog and authors are still needed for tarballs, but maybe they
can be
Hi,
I'd like to revive this thread[1]. I wasn't around during the initial
thread but Jiri has just pointed me to it and I read it through. I'd
like to summarize (at least my take) on that thread and then list some
pros and cons to stimulate a discussion.
Disclaimer:
I am not an expert on
Nice summary Matthew,
As far as I remember it, seems to be accurate.
Summary from previous thread:
The people in the thread who do not want to switch to Git, or those who
don't seem to care either way, are those who have commit access to
Subversion on SourceForge. Most (if not all)
On 04/27/11 21:01, Lex Trotman wrote:
- No need to maintain changelog and authors files
Changelog and authors are still needed for tarballs, but maybe they
can be automated?
Seems not too hard with git log and some shell script[1]. I think the
original thread also mentions a way (or that
29 matches
Mail list logo
