We use Git on the Corinthia incubator. For Apache committers, there is not much difference in how one makes commits and it is much easier to work on branches for anyone. Using clones does add a step between change and commits at the Apache origin repo, as Yuri observes.
Users of SVN who have not delved into Git may find some of this helpful with regard to the main effects. - Dennis THERE ARE BASICS PRETTY MUCH THE SAME BUT ... The nomenclature is different. Clone is the counterpart of the SVN check-out. Commit is not the counterpart of SVN commit. A Git clone is a local full repository and a working directory with the files that are initialized to the current head of that clone. The working directory is essentially a particular view into the clone repository along with any changes made in that working directory that have not yet been committed to the clone repo itself. My experience is that what I just said broke my brain. I had to let go of how I look at using SVN and just let that soak in as I began to understand how Git has local operation work. I have a clone of the Apache-hosted Git on my windows desktop. It serves me just like an SVN working copy, and even looks the same in terms of what I see in working folders (except I use TortoiseGit for one, TortoiseSVN for the other). Now, when I have worked on changes in that working copy, a commit goes to the *local* clone, not to the Apache origin. This works without my having to be online or even connected (unless the clone is on a network share). I usually use the GitHub for Windows application to do this, even though the Apache origin repo is not on GitHub. The GitHub app works fine with all Git repos on my system. The value of the GitHub application is that it shows me quickly what local working material is not committed and lets me selectively choose what to commit and write the commit message. This is still done on the clone. The other value of the GitHub application is that it shows me whether there are changes at the origin that I have not synced with, as well as showing how many commits I have not pushed to the origin. In a single Sync operation, I can pull down all the recent changes from the origin and, because I am a committer, directly push my recent changes up to the origin. Any conflicts will not impact the origin, but will require me to fix them locally first. A safer way, is to pull down the changes from the origin first, to ensure there are no collisions, then do a push (or a sync because it is just handy) to line up mine and the origin. I found that it took some baby steps, but I now do that easily and without effort. The big difference, which does not intrude on ordinary processes such as I have described, is when you want to revert a commit to the clone. The Clone has the *complete* history of the origin repro, as of the latest sync. You can dig into it entirely locally. And if there is some sort of disaster, someone with a good clone can completely restore the origin or otherwise preserve the repo (but for origin changes not synced at the time of disruption). You could, in principle, also fork a project by having a clone that you never/rarely sync to the origin but that you continue to pull down origin changes from. There is probably some set of git operations and options to make all of that work and allow the pulls down from the upstream origin to be reviewed and pushed to the fork's origin repo. I can imagine such a structure where patches made to the upstream origin's code could be made available via pull requests to that origin but the unique material on the fork is not offered. I've not dug into git enough to know how to pull all of that off, but that would work in cases of externals that AOO relies on and that we have had to patch to work as an AOO dependency. We would want to provide some upstream patches to an external git repo for the originating project to accept or not when are changes are general fixes or improvements. BRANCHING IS EASY AND OFTEN The difference about branches is profound, especially for a large repo such as the Apache SVN. In SVN, there is essentially a full copy of some part of the repo. It is not *literally* a copy, but as either a branch file or the original file change, the branch file does become a separate copy. However, a checkout of the branch is definitely a full copy. Messy. With Git, when you start a branch in a clone, nothing happens. Basically, your working copy, currently identical in the branch and the trunk (often called master in Git repos), just sits there but it is labeled the branch. You can work on the branch and when you commit locally, you are committing to the branch. If you switch back to the master, you will see the master without any of the branch changes. If you switch back to the branch, your local working folder will have the master from the point the branch started, updated with all committed changes made on that branch. This will happen instantaneously, especially for small experimental branches. In a common situation, in working out a small change, for example, you can sync your working copy (set to master) with the Apache origin, then merge the branch to master, resolve any conflicts that might arise, and then push the resulting changes with the merged branch back to the origin. I've done that. I haven't had to deal with any collisions on Corinthia yet, but I have had them elsewhere and it is intriguing how that works. I have also made throw-away branches where I was experimenting and then simply left the branch to die. I think I deleted such a branch (although it does not really disappear), but I've forgotten. WHAT ABOUT NON-COMMITTERS Non-committers can't push back to the origin server. But they can clone and do everything on their clone-tied working copy as anyone (just as for an SVN check-out). They need to learn how to derive patches and submit them, ideally attached to issues. (I have not broken the code on that. My diffs refer to locations in my local file system, and I haven't figured out how to get around that yet.) But non-committers and even committers (on a very large project) have another way to do this, so long as their clone is accessible on the Internet (on GitHub, say). Someone working on a clone can develop a branch that they propose for inclusion in the origin. They can issue a pull-request to the origin. This notifies someone who is supporting the origin repo that there is a request and they can review the request, inspect what the changes are, and choose to selectively pull the changed material to the origin repo, preserving the branch or not depending on circumstances. There are some involved matters about requiring an iCLA from anyone making a substantial pull request and ASF has some rules about how provenance is preserved while requiring that a committer be the one to make the commits to the origin repo. I haven't gotten into this very much at all, since I am a Corinthia committer and we've received no pull requests at this point. Linus Torvalds has an interesting way of working with these for the Linux Kernel. The pull requests get to what are called lieutenants who are experts on various parts of the kernel. The lieutenants review pull requests and make any change to *their* clone of the kernel repo. Then the lieutenants make pull requests "upstream" to Linus, who then can do the same, satisfy himself, and do the pull. (I think it is a bit more streamlined than that, so no one has to go through too many steps to review and accept/reject the many pull requests that come in.) That doesn't quite fit the organization of Apache Projects and how there is no hierarchy of committers, so I haven't dug too far into it. My picture here is therefore rather sketchy. -----Original Message----- From: Yuri Dario [mailto:mc6...@mclink.it] Sent: Wednesday, February 18, 2015 02:54 To: dev@openoffice.apache.org Subject: Re: [PROPOSAL] move repo to Git. Hi, a bit late... having worked with both svn and git, personally I don't think git it is easier to use. Given how AOO is developed, it seems to me that cloned repos are not necessary, developers are already working on svn repo. -- Bye, Yuri Dario --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
