Migrating to git?
After a discussion with Robin Mills on the tracker, he asked me to give my opinion about maybe passing to git, or another decentralized source repository.
First of all, I want to emphasize that I don't plan on becoming an Exiv2 regular developer. I just happen to use it as dependency for other projects. So I sometimes have to compile it, and — why not — make a patch here and there if needed. So in the end, you are the ones to decide what suits you best. I won't have my voice on the vote, but will tell why I prefer git to svn as a contributor.
I see many advantages to git: branches (which are not copy-paste of the whole tree, annoying to merge back to the main tree when it diverged a lot, etc.), working out of the network (it depends on people. Some are always connected. But I have regular occasions when I code without a connection. Not being able to check the logs, make diffs, checkout old commits, etc. makes life very complicated when working on a project with svn), very neat commit management, and so on.
Also I am always checking the right syntax to make and apply patches with svn. Do I have to patch p0? p1? It depends on how the contributor made the patch. Etc. On git, you ask the contributor to `git format-patch origin/master` and you `git am the-contributed-patch.patch`, you check, optionally ammend the commit and you push. You even keep the commit description and the authorship of the commit (the contributor, not yours!), which is very appealing to contributors. I have contributed many patches to many svn projects, and except the ones where I had my own svn account, I don't have my name in the logs (it can be in a commit message, or in a README or CONTRIBUTORS or AUTHORS sometimes, if the project people don't forget to add it which don't happen that often actually, but not in the logical place: the commit author). I still contribute but you could say that's not as welcoming (so potentially less contributions for Exiv2). This is also good for you, to efficiently manage your contributions (who wrote what?), etc.
And last but not least, I find git a lot easier. But this one may be because I have mainly coded on git projects in the last years, and have not come around many svn projects lately. So I kind of forgot most of what I used to know about svn. :-)
That's it. Bye!
RE: Migrating to git? - Added by Gilles Caulier about 7 years ago
As KDE developer who has follow svn to git transition, i can said, that git, is powerful, but too powerful. It's a bulldozer to make a small hole (if i talk about Exiv2 project). This tool is perfect to manage huge projects, with a large amount of developers / contributors (as Linux), but for medium and small projects, git is not very well adapted.
Too much commands are obscurs and complicated compared to svn. Personalty, i take one year of active development with digiKam & co to drive git in medium level. I discovers new options everyday.
So, a svn to git transition is not a small task. Take a care. I recommend to do it when time permit after a major release.
RE: Migrating to git? - Added by Andreas Huggel about 7 years ago
I've been using git for my Exiv2 development (however little that has been lately) for quite some time, using the git-svn extension (see below). Nothing should stop you from doing the same, although I'm not sure how that feature about contributor-ship works in this setup. But I agree with Gilles: Git is not a simple tool, and I have no problem getting myself into a situation where I don't know what to do anymore after issuing just a few git commands. But thanks to the git-svn extension, we can have an svn repository, which is all we really need, and anybody who likes can still use git for their local development (we even have a .gitignore file in the repository).
These are the few commands I use (copied verbatim from an old email from Volker Grabsch from 2011):
 If you want to get started, I recommend to run the following command: git svn clone -s svn://dev.exiv2.org/svn exiv2 This will take a while. It will download the whole history of trunk and all branches. Afterwards, the working directory will point to the latest trunk revision. Afterwards, you should optimize the repo: cd exiv2 git repack -ad Note that for Exiv2, the overhead of Git is just 12 MB, containing the whole history. Compare this to Subversion's overhead of 27 MB containing just the latest revision. Instead of "svn update", you'll do: git svn rebase Instead of "svn commit", you'll do: git commit -a git svn dcommit For more information, there are nice tutorials and manuals.  There's only one drawback: It is tricky to add commit messages that start with a hash (#), because such lines are usually ignored by git. There are some ways to circumvent this , the easiest is not to use a text editor but to provide the commit message at the command line: git commit -a -m '#772: Applied patch to recognize ...' git svn dcommit  http://www.viget.com/extend/effectively-using-git-with-subversion/ http://www.kernel.org/pub/software/scm/git/docs/git-svn.html http://git.or.cz/course/svn.html  http://stackoverflow.com/questions/2788092/start-a-git-commit-message-with-a-hashmark
RE: Migrating to git? - Added by Jehan Pagès about 7 years ago
Seriously I read your comments about git being more difficult than svn, but I really don't get it. That's just another program, and as such obviously you learn new paradigms. It's all just a question of getting used to it, basically. Isn't it what we constantly do as software developers (new languages, new programs, sometimes that we build, sometimes that other did)?
As for my own, I used to use svn regularly, years ago. And I was therefore more proficient than I am with git. Nowadays that's the opposite. There are so many things I don't know how to do anymore with svn, but they just come naturally with git. Why? Not because svn is about "homeomorphic endofunctors" or some other funny (or not) joke. Just it's about getting used to new tools. To get back at your example of getting into a blocking situation, I actually had it the other day with a svn project, which forced me to check it out from scratch because I could not find how to reset cleanly my repo (note: I don't say it is not possible, just that I could not find how!); whereas with a git project, I can always come back to a bare repo in a few commands, and this even without a working connection. The point is that this was not a good example because it can be reversed too, since it just all depends on how proficient one is with a particular tool. :-)
Anyway I was just saying, I should maybe not have brought this topic up. Also about saying Exiv2 has few contributors: maybe it could have more with a versionning system which encourages people to contribute (i.e. not svn). Exiv2 is getting used in quite a bit of big projects now, and metadata is a big topic nowaydays (in Libre Graphics Meeting, there are always a few conferences/workshops related to metadata). No reason Exiv2 could not get much more contributors.
RE: Migrating to git? - Added by Robin Mills about 7 years ago
I don't have any issue with the idea of adopting git. I've only heard good things about it. My reluctance is the period of confusion as the team comes up to speed. I'll put this on the agenda for the next team meeting. Provided a team member agrees to be "Mr Git" and hand-hold us through the inevitable pain of adoption, I'm OK about this. No "Mr Git". No Way!
I think this is a Python vs Perl, C++ vs C kind of thing. The superiority of the new guy on the block is not in doubt. However the frustration during the adoption period is real. Something to deal after we've shipped 0.25.