[jsword-devel] Git

Tue Mar 13 10:48:59 MST 2012

Just to say - git intimidated me as a noob enormously, but I was searching for a solution to keep track of texts I am working for modules - often across several computers and with some branching.

I am now using git for all my module work, for several websites I maintain and for all kinds of other stuff. 

It is easy and elegant where svn was hard work and really offered me an enormous increase in speed and security.

I do think if I got my head around it, more intelligent mebers of this list will do so easily.

Peter

-------- Original-Nachricht --------
> Datum: Tue, 13 Mar 2012 13:38:43 -0400
> Von: DM Smith <dmsmith at crosswire.org>
> An: jsword-devel at crosswire.org
> Betreff: Re: [jsword-devel] Git

> Thanks Matěj for the info. I will look into it. You've given me several 
> good starting points.
> 
> In Him,
>      DM
> 
> On 03/13/2012 01:07 PM, Matěj Cepl wrote:
> > On 13.3.2012 16:26, DM Smith wrote:
> >> No serious discussions. The major issue is that there needs to be a
> >> master copy of the code, with all others ultimately being branches
> >> of it. Since git can be layered over SVN, we can have SVN be the
> >> authoritative, master copy and the layers of git be the branches.
> >> Finally, there needs to be a small number of people that are
> >> gatekeepers of the master.
> >
> > I have no bones in this fight, just to note that git doesn't have to
> > mean that each git repository is equal to each other. There is the
> > Linus' repo to which only he has an access, there are special central
> > repositories for all other projects I know about to use git/mercurial
> > (Xorg, Mozilla, Gnome projects).
> >
> >> This is more a problem with how we are using SVN. The model that we
> >> should use is to have trunk be the next release and tag each release
> >> from it (as we are now doing), but also to create a release branch
> >> for each tag when needed to solve bugs, add translations, etc.
> >
> > That's just a question of the workflow. Master should be the same as
> > trunk in SVN, meaning that only the accepted official commits should be
> > there. ALL development should be done on topical branches, which only
> > when accepted should be merged into the master branch of the centralized
> > repo (from which all other masters should be pulled).
> >
> > See for more
> >
> > http://schacon.github.com/git/gitworkflows.html (manpage provided with 
> > git)
> > http://progit.org/book/ch5-1.html (the best book on Git, online as well
> > as offline)
> > http://nvie.com/posts/a-successful-git-branching-model/ (I don't follow
> > this one, but it is one of the best thought-through ones).
> >
> >> In the case of av11n, it should have been done on a branch because
> >> of how disruptive it is. Basically, a feature that cannot become
> >> stable in a few weeks shouldn't be implemented in trunk.
> >
> > NO feature should be developed on master.
> >
> >> I understand how this increases collaboration, but I have some
> >> concerns. They might be/probably are based on a misunderstanding of
> >> how git works. I think that by layering git over svn, my concerns
> >> probably are satisfied.
> >
> > This is not a good solution. Meaning, certainly it is better than just
> > SVN, but everybody using git allows much more sophisticated cooperation
> > (e.g., topical branch in the centralized repository ... everybody can
> > cooperate on it, but it is not the official master yet), merging between
> > two git-svn-generated repositories is not that great (as git cannot use
> > commit IDs for identification of the shared points).
> >
> > In the end you would really need a blessed official git-svn RO mirror.
> > When you have that there is really no point
> >
> >> Part of my problem is that I know and am comfortable with svn. I'm
> >> not eager to try something else, especially with a non-trivial
> >> learning curve, if the problem can be solved simply in svn.
> >
> > There are tons of documentation for former SVN users
> > (http://git-scm.com/course/svn.html is usual startpoint) and it is
> > really not that difficult. I have seen (and helped a bit) to my
> > colleague migrating all his work related work from SVN to Git (he is a
> > maintainer of a large sub-project inside of JBoss). Week later, he was 
> > on fire for git; he even bought with his own money a special computer, 
> > just to host his complete copy of all JBoss repos cloned via git-svn. 
> > Three months later, whole open source JBoss is primarily hosted on 
> > github (https://github.com/jboss; I believe maintained enterprise 
> > versions are still in SVN inside of VPN). I am not saying I was the 
> > only git fan helping them to see The Light (here in Red Hat it is only 
> > git all the time everywhere), but the speed with which he, as an 
> > experienced professional SVN user, (and his colleagues) made and 
> > embraced the shift was impressive even for me.
> >
> >> Maybe it is time I took a serious look at git.
> >
> > Indeed. If you need any help in this department, feel free to ask.
> >
> > Best,
> >
> > Matěj
> >
> 
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de