Switch code repo to github and start using pull request workflow

[gcode-importer]

Originally reported on Google Code with ID 373

Git and pull request workflow make it much easier for third
party developers to submit complex patches that involve multiple
commits. And it is easy to make comments on the code and request
changes.

Don't be on the wrong side of history :)

Reported by boxerab on 2014-07-06 01:18:02

[gcode-importer]

Ok migration to another repo takes time and effort and might confuse people having the
repo URL in some config file. So I don't want to dive into this without being sure
it can improve the project significantly.

So I need some more information / advices on this. 

Some inputs : 
* Googlecode allow switching to git repo if needed
* git-svn works fine locally to interact with a svn repo
* downloads are already hosted at sourceforge ... Is a complete switch to Sourceforge
also an option ?
* what about migration tools ? We would need to migrate all repo history of course,
but also issues, opened and closed

Reported by detonin on 2014-09-16 13:55:34

• Status changed: Accepted
• Labels added: Type-Task
• Labels removed: Type-Defect

[gcode-importer]

git is only useful when dealing with complex branching/merging strategy. OpenJPEG has
very very limited usage of branch (patch from 1.x to 2.x are manually merged since
code is so different).

I doubt there is any real advantage in using git as main VCS for openjpeg. BTW nothing
prevent users from using git-svn and have full git power on there client. 

Please submit single, well tested, clear patch on the mailing list. The github workflow
may work for others, we did not required it for the past 10 years or so. 

Footnote: I am biased since github is a closed-source platform.

Reported by malaterre on 2014-09-16 14:01:14

• Labels added: Priority-Low
• Labels removed: Priority-Medium

[gcode-importer]

Mathieu - you are right regarding bug fixes, where SVN more than suffices. But from
my experience with working on new features, branching helps immensely.

If the feature is complex, then it will require multiple commits, and this context
is lost when submitting a patch.  Github allows patch developer and repo maintainers
to make comments on the code being submitted (these comments appear right next to the
relevant lines), request changes, re-submit the changes, and the history of this code
conversation is saved and available for viewing.  

Since SVN has such poor branching support, it is not surprising that OpenJPEG has not
used many branches over the last 10 years. But this doesn't mean it will not be useful
in the future, if it is easy to use. There is a reason why SVN adoption is dropping
and many new OS projects use Git.

Gits excellent branch support encourages other developers to fork the code and add
features they are interested in, and easily keep up with changes in the forked repo.


Another nice feature is git rebase - when developing one often wants to make checkpoint
commits where the code is at a sane state, but the feature is not complete. After the
feature is ready, it is possible to combine these commits into one polished commit
using git rebase. I use this feature a lot when working
on a feature branch,  just before I merge into the master branch.

I could go on, obviously I am a git fanatic! 

Regarding Antonin's questions: 

Yes, googlecode supports git, but the Github workflow using pull requests is really
nice. To submit a patch, you simply fork the parent repository, make the changes in
a branch, and press a button to submit these changes as a "pull request". If the maintainer
likes them, they can often automatically merge the changes in. Otherwise, they can
request changes, and go back and forth until everyone is happy. I have found it much
easier to use than manual patch submission.

We can port over the entire SVN repo with history into a git repository. I have already
done this on my mirror:  https://github.com/OpenJPEG/openjpeg
Under the "branch" button you can switch to all of the SVN branches. 
The only thing missing would be the author information, since I don't have access to
the authors file.

Regarding moving the issues, there are scripts out there to do this, but I haven't
tried them.

Downloads can be hosted at github too.

And yes, there is a learning curve. It will take some time to get used to the new tools.
But, well worth it, in my opinion.

Finally, last time I checked, google code and sourceforge were also closed source platforms
:)

Kind Regards,
Aaron

Reported by boxerab on 2014-09-16 15:03:33

[gcode-importer]

Here is an article outlining the rising fortunes of git, and the decline of SVN:

http://readwrite.com/2014/01/21/git-subversion-developers

Reported by boxerab on 2014-09-17 01:28:01

[gcode-importer]

Hi,

I do not use git myself (for now) as my company heavily relies on Subversion. Nevertheless,
when dealing with opensource libraries, I can sense that I spend more & more time on
GitHub to browse source code/check changes/retrieve tags...

The adoption of Git by the opensource community has been growing for the last few years
& is now (from what I've read) used more often than Subversion.

Since I don't really use git, I rely mostly on what I've read here & there. But what
I could sense while browsing GitHub, and as Aaron pointed out, the GitHub workflow
encourages developers to fork, make their own branches for new features or bugfixes.
Git being much more "merge friendly" (that was one of the reason it's been developed
in the first time) than Subversion, it will be really easy to merge back fixes & new
features in the mainline SVN (& for those developers, to merge the mainline in their
branches on the go).

As I said, this more of a feeling than concrete experience. Nevertheless, seems the
way to go.

As Aaron pointed out, GitHub, GoogleCode, SourceForge are all closed source platforms
relying on opensource software so no difference there.

Regards,
Matthieu

Reported by mayeut on 2014-09-17 07:52:16

[gcode-importer]

@Aaron: we're investigating migration to github. One thing I couldn't find is how to
attach files to issues ? This is something we use *a lot* in OpenJPEG, attaching corrupted
J2K files, and so on ... Do you have any comment on this or advice for a solution ?

Reported by detonin on 2015-01-23 09:24:02

[gcode-importer]

https://github.com/blog/1347-issue-attachments

Reported by boxerab on 2015-01-23 14:28:17

[gcode-importer]

@Aaron: This is only for image attachments (png, gif, jpg). By any chance, are you aware
of any solution to attach other files (like JP2 files ... Which is very often the case
when opening an issue in OpenJPEG) ? Thanks

Reported by detonin on 2015-01-27 14:06:29

[gcode-importer]

sorry, don't know how to do this.

Reported by boxerab on 2015-01-27 14:16:12

[gcode-importer]

I stumbled on this page while looking for something else, but this may be useful to
you for attaching files:

https://github.com/ljosa/issues-with-attachments

In particular, it might be integrated with github's Large File Storage:

https://github.com/blog/1986-announcing-git-large-file-storage-lfs

Reported by thouis on 2015-05-21 13:00:38