Public Git repo

[Yawar Amin]

Hi Derek,

You have some good points. See below:

On 2011-01-02, at 20:56, Derek Atkins wrote:

>> […]
> 
> I think it is premature to have a "canonical" git repository.
> 
> […]
> 
> HOWEVER
> until we, the set of developers, decide as a group to migrate to git we
> should not bless any tree as "the canonical tree”.

This was actually why I suggested a ‘gatekeeper’ Git repo which we use to access the canonical SVN repo.[1] Any devs comfortable with Git will use the gatekeeper, and any devs comfortable with SVN will use the canonical. The gatekeeper will be a perfect mirror of the canonical, except it will be out of sync by a few hours to a day (or not even that, depending on how we automate the syncing process). Thanks to git-svn, this is completely possible and what a bunch of people are doing now.

> I suspect it will take
> a number of experimental migrations to make sure we get a complete
> migration including history.

Actually, Git’s history import is pretty much rock-solid. The only thing that’s less than perfect is that author names and email addresses aren’t automatically imported. But this can be solved by giving the importer a map file like the following:

yawaramin = Yawar Amin <yawar.amin at gmail.com>
…
bobsmith = Bob Smith <bobsmith at example.com>
…

I can prepare a map file. But before I do that, let me just ask: would we mind not having the full names and email addresses of historical committers in the Git history? We know who the contributors are, they’re listed in the relevant AUTHORS files and other places; plus their usernames (lapham, wilddev, cstim, warlord, etc.) are in the commit history. Just a thought. Commits made into the Git repo will of course have names and emails.

> So..  Feel free to play with git.  But don't expect your SHA history to
> remain 100% complete or that the repo you create will at all resemble the
> "offical" git repo, assuming we do change over to git.

I think a bunch of us have been using Git (git-svn to be precise) to interact with the canonical SVN repo for a while now. The gatekeeper repo would just simplify things for us–it would move the synchronization step into one point instead of spread out among the (several? many?) Git users.

If we did change over to Git, we’d just clone the gatekeeper repo, put that cloned repo on the GnuCash server, and call it the ‘canonical’ Git repo–so actually, the commit SHAs would be exactly the same :-)

> And for the record, I feel using github would be okay for these trials,
> but the official git repository should remain on our own server. 
> (Creating git.gnucash.org as a cname for code is perfectly reasonable, if
> we decide to move to git).

Sounds good to me.

> So let me push this back to you and ask:  Why do you want git?  What does
> git provide that we're not getting with SVN (other than personal,
> "offline" branches,

Compared to SVN: topic/feature/bugfix branches. For example look at [2] and notice how each bug I’ve worked on has been in a separate Git branch. That history has been squished flat by SVN, but Git remembers the branchy development. Easy experimentation without getting in anyone’s way or cluttering the source tree. E.g. look at [3]. We could have a hundred of those in Git branches and maybe some of them would be the next killer features. Easy merging. Easy backup of full history (every dev with a clone of the repo on their computer effectively has a full backup). OpenPGP signatures on tagged commits. SHA1 verification of repo integrity (tamper-proofing, malicious intent or otherwise). Built-in author attribution–Git records both who authored the patch and who committed it to the repo. And, not directly a Git feature but still: GitHub is pretty cool :-)

> which you can get through git-svn

Compared to git-svn: a simpler, more streamlined workflow. Not having to remember arcane implementation details (i.e. git-svn looks at the ‘left’ branch when doing a merge to figure out what SVN revision to merge into). Efficiency gain by syncing at one point instead of all git-svn users syncing individually.

> or svk or a number
> of other tools)?

Compared to svk: can’t say. I don’t know svk. :-)

Anyway, to end with a clear next action: John, would you be kind enough to create a ‘gnucash’ organization on GitHub and upload your repo there? I would like to clone it and try working on #634456.

Regards,

Yawar

[1] I tried to avoid the word ‘canonical’ in my previous email because it sounds like a certain famous open source software company … but anyway. :-)
[2] https://github.com/yawaramin/gnucash-docs/network
[3] http://svn.gnucash.org/trac/browser/gnucash/trunk/src/experimental

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20110103/1e38fe5d/attachment-0001.bin>