Git Version Control

Submitted by lm4 on Wed, 2016-05-11 21:32

Forums:

It would be nice for the project to use Git.
I've been using git-svn internally, which only really supports linear histories. Using Git for the project's VCS might accelerate development, given it's current popularity and ease of branching.
Pull requests also make it easier to integrate contributions.

jcf

Thu, 2016-05-12 02:10

There's no need to sell me on Git; MOC development is based around it (via git-svn). There have been e-mail discussions in the background over the past two weeks around moving to Git, and the mood is very positive. But time is the main impediment (as usual); it's not like there is a large team behind MOC to absorb the work.

I agree with everything you say, but there's a large backlog of uncommitted contributions which are now being worked through. Changing VCSs in the middle of that is an unnecessary distraction just at the moment which would further delay wished for end-user features.

However, there is an interim solution which may be available to us and is under consideration.

lm4

Thu, 2016-05-12 15:37

Great to hear. Thanks.

sebastian

Fri, 2016-06-10 21:52

I've been working on a small patch to MOC which I wanted to put online somewhere and as a heavy user of it GitHub seemed like the right place for me. I did not find any 'clean' mirror of MOC's subversion repository on GitHub that I could fork to my personal account. With 'clean' I mean a mirror without unofficial additions. So I set up such a mirror under a new organization called 'console-tools' ('moc' was already taken as a username/organization name). I do not plan to add any commits to this repository myself, just to keep it in sync with the SVN for the moment.

The repository has been cloned using the 'svn2git' tool to preserve the commit history. I understand that you consider migrating to Git a distraction at the moment and working on it does not have priority. Anyway I wanted to let you and the community know about this. Should you be interested I will of course also make you admin of that repository/organization. Here's the link:

github.com/console-tools/moc

If you find this useful, please let me know. I'm available for making the import from SVN optimal. One thing that's broken for now are the commit author email addresses of the three SVN committers (because I don't know which ones to use).

jcf

Sat, 2016-06-11 01:31

Thanks for that, "sebastian". Unfortunately you've come into the middle of an ongoing effort. I'll need to discuss things with you by e-mail.

rayden

Mon, 2019-08-12 14:46

It has been quite a while. Would it be possible to give priority to the git migration?

I believe snv is hindering contributions and I am afraid the project might be seen as dead (although I know it isn't). Which means less users and even less contributors.

jcf

Wed, 2019-08-14 21:59

It has been quite a while. Would it be possible to give priority to the git migration?

I'm painfully aware of how little time I've been able to put into MOC over the last few years. The Git migration is still planned but doing it now with so many pending commits would increase the effort required significantly. The priorities at present are bug fixing first and releasing MOC 2.6 second.

Migrating to Git is not as straight-forward a task as one would think. There are tools which produce a Git repository from an SVN one, but that's only the start. My experience, and that of others whose migration accounts I've read, tells me that cleaning up the repository and presenting it as consistant with the Git culture is a must. I have been structuring SVN commits in a way which will make that effort easier, however.

I believe svn is hindering contributions...

I agree with you, but the other side of that coin is that time to handle those contributions can only be found by taking it from that for development. I'd rather put the effort into getting the planned features into MOC than integrating contributions (which often conflict with intended direction of the codebase anyway).

In the interim, I can recommend the use of Git-SVN, and have been using it myself for MOC since I took over maintainership. It gives you a working Git repository which interacts well with the SVN one. However, it does not provide a community platform such as GitLab does or Gerrit did (AFAIK it's still GitHub-comprimised).

So, I'm sorry. My sentiments are the same as yours, but it is what it is.

rayden

Fri, 2019-08-16 14:41

The last thought to cross my mind is I don't want to see the project die, hence the suggestion.

Hopefully you gather the time to merge the pending commits and release the new version.
I can help with the git migration if needed.

teto

Tue, 2021-10-19 12:44

I've been using mocp ever since I've discovered it, probably around ~10 years IIRC.
I wanted to look into submitting a patch (support truecolors) but looking at the website, it's hard to tell about mocp's development activity, I was not sure getting the svn version would get me the latest version.
Moving to a github repo would make things clearer. As a regular foss contributor, I know how handling contributions can be a pain. Putting this under an org under github could help others do the review.

tomaszg

Tue, 2021-10-19 12:50

SVN version is the most up-to-date. It is very unlikely that MOC will move to Github, rather to some other hosting service which is not owned by a particular unmentionable company.

As for the truecolor support - I did some basic work some time ago in my personal fork. All was needed was to be able to read these colors from theme file: see this commit https://gitlab.com/tomaszg/mocp/-/commit/7f216ab71dfc883d0d9a2ae083613445b012dee5 (with a correction in the next one as well).