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


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 

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 

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.


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.


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 

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.


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.


        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

Reply via email to