Public Git repo

[Derek Atkins]

Yawar Amin <yawar.amin at gmail.com> writes:

>> 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.

Sure, this is fine for a "test" platform, which is what I meant.

>> 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:

Apparently there are also issues with importing branches and tags
appropriately, as per John's other email.

[snip]
>> 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.

Do we really have a synchronization problem?  What exactly do you mean
by that?

> 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 :-)

*THIS* is where I disagree.  After we get some experience with git and
after we'd figured out the proper incantations to completely migrate
from svn, then we should *not* work from the gatekeeper repo but instead
we should start with a fresh "Master" repo off SVN and make that the
"official" repo.

> 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. 

Is remembering the 'branchy development' really a requirement here?  SVN
certainly supports feature and bugfix branches, and we've certainly used
it that way.  It does have a problem that you cannot really merge
multiple times, so you have to worry about multiple merges from a branch
back to trunk.

>   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. 

Here's where I have to question:  does this experimentation have to
happen in a way that is easily publically published?  In what way does
the status quo not allow this?

>   Easy merging. 

I would still put "Easy" in quotes, because you still have to manually
deal with code divergence..  And that is really the hard part of
merging.  Assume you have three branches of development (trunk and 2 dev
branches).  Dev branch 1 makes some major changes to the tree.  Dev
branch 2 makes different major changes to the tree.  Dev branch 1 gets
merged back to trunk.  You then have to manually merge those changes
into Dev 2 before it can merge back to trunk.  Now take this problem and
ramp it up to 100 dev branches!

No SCCS makes this job easier... And *this* is generally our problem.  I
don't think this is any easier in git than it is in SVN.  I'll note that
git does make it easier to rebase and merge more frequently (and
multiple times in both directions).  But let's not ignore the hard
problem, which git still doesn't solve.

>   Easy backup of full history
> (every dev with a clone of the repo on their computer effectively has
> a full backup).

We already get this via a number of methods, including rsync to the
server, and also using tools like svk or git-svn.

>    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

I don't think these features matter all that much, do they?

> feature but still: GitHub is pretty cool :-)

It may be cool, but we don't control it.  :-/

>> 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.

I think any system has its own archana.  It's all a question of what
you're used to and what you know.  Learning a new system always takes
time.

>> or svk or a number
>> of other tools)?
>
> Compared to svk: can’t say. I don’t know svk. :-)

See, you should look into svk!  SVK provides many of the features you're
asking about.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available