Public Git repo

[Derek Atkins]

Matthijs Kooijman <matthijs at stdin.nl> writes:

> Hey Derek,
>
> a few notes on this, from a patch submitter's point of view :-)
>
>> >> 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?
>
> I think the "synchronization" meant here is the regular import of SVN
> revisions into a git repository. Currently, a bunch of developers do
> this on their own systems (and especially the initial import is a lot of
> work), so there is some double work.

I think that's irrelevant to this discussion.  You're assuming already
that you're using git and complaining that the source isn't in git.
That's not the point or the question; the point is "what features are
you getting by git that you don't get from other tools?"  So the
question here is: what's the "subversion" synchronization problem?

>> *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.
>
> Do you mean a completely new repository, without history, or just redo
> the entire import? If the latter, I guess I agree (though if we redo the
> import a few times during the experimentation until we are happy with
> the result, a re-import might not even be needed).

The latter (redoing the entire import).  It's certainly possible that
we'll re-do it through experimentation, but the fact remains that what
gets done this week might not be the basis for the "final" version of
the repo.  Assuming, of course, that the choice is made to jump to git.
That choice has still not been made.

>> > feature but still: GitHub is pretty cool :-)
>> 
>> It may be cool, but we don't control it.  :-/
>
> I think the main advantage of something like Github is that people
> (developers and non-developers alike) can easily publish their
> experimentations. This can of course happen with git-svn as well, but
> having a public git repository makes things easier for people.

Sure, but that doesn't mean we need to use github for the main source.

>> > 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.
> One of the things I totally like about git (and thus git-svn) is its
> history rewriting capabilities. You can just start working on a patch
> series, doing selective committing with git add -p, and edit patches
> later on using git rebase and --amend, etc. This is ideal for developing
> and polishing patches before they are submitted or committed.

SVK lets you do it, too.  When you merge back into trunk you can decide
to combine all your patches into a single changeset, or make them in a
series of changesets (although the former is easier).

> I know that there are other tools for this (I've used quilt in
> particular), but git just makes this so very painless and Just Work.
>
>
>
> I guess the summary is that I rather like git and that having an
> official git repository (either on top of an svn repository or as the
> canonical repository) would make it easier for people to get started
> on GnuCash using git (or to start using git altogether, which I can only
> encourage ;-).

I understand the "I like git, so everyone should use it" mentality.  I'm
trying to make sure we don't move over to git only because of that.  I
want to make sure there are real technical reasons to spend the time and
effort to not only migrate the source repository but also migrate all
our tools and configurations to use a new set of tools.

It's not zero-effort.  There's a bunch of backend scripts and ties that
get used.  If we move the git we'd possibly lose trac (or we'd have to
migrate to something else).  We'd have to re-script all the automatic
build scripts and tools.  We'd have to rework the server,
authentication, and access policies.

At the end of the day, I feel the question is does git buy us so much
that it's worth the pain to convert?

I get the "git is cool" aspect of it.  But I'm trying to get people
ignore the "git is cool" part and to seriously think about the
technicalities: what does git buy us that we don't have now, and will we
really truly use those features that git provides that svn (or other
tools built on svn, including git-svn) does not?

> Gr.
>
> Matthijs

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