[En-Nut-Discussion] Switching to GIT

[bon at elektron.ikp.physik.tu-darmstadt.de]

>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

    Harald> Uwe, On 26.09.2013 11:03,
    Harald> bon at elektron.ikp.physik.tu-darmstadt.de wrote:
    >>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
    Harald> Why keep SVN as the "Git master"?
    >> 
    >> Because switching to either git or hg implies policy and maybe will
    >> leave (parts of ) one group unhappy.

    Harald> The current status is, that all active developers are happy with
    Harald> moving from SVN to a distributed VCS. Some would prefer
    Harald> Mercurial in the first place, but would prefer Git over SVN
    Harald> anyway. Correct me if I'm wrong.

I prefer git against svn. But as git has a module for SVN, it nearly doesn't
matter for me if the Erhernut repo is SVN, hg or git. I checkout ethernut
locally as a "git svn" repo and normally work on a git repo. What does it
offer for me if we switch the central repo to git?

And maybe hg users also have their hg svn workflow. If we change the central
repo to git, they have to change from "hg svn" to "hg git". What does the
change offer for them?

    Harald> Today I create a new SVN maintenance branch before releasing a
    Harald> new final version and tag the trunk at that point. Can I do the
    Harald> same on my local Git repo and will that be automatically
    Harald> transfered via "git svn commit"?
    >> 
    >> The principal command is "git svn dcommit"
    >> 
    >> Well, there is "git svn branch <branchname> " and "git svn dcommit
    >> <branchname>" that imply it can be done. I didn't test however yet.

    Harald> Until now I'm almost the only one who merges bug fixes from the
    Harald> trunk into maintenance branches. Considering my limited time,
    Harald> I'm a bit concerned about any additional complexity.

Come on! Where is the added complexity?
With git you also have to create the branch and push it to the central
repository.

    Harald> Git allows a developer to pull from an untrusted source, check
    Harald> the changes, and, if it looks fine, send a pull request to the
    Harald> master. How to do that with SVN? Will the change be directly
    Harald> committed by the developer, who received the untrusted change?
    >> 
    >> Als not tested. But I guess you pull in the changeset locally and
    >> than you push to SVN with "git svn dcommit"

    Harald> Not really sure, if this answers my badly verbalized question. I
    Harald> was more referring to the role of the developer and the
    Harald> maintainer.

Well, I have not seen yet such patchsets or pull requests on the mailing
list. But I have pulled changes from local branches to local master and
dcommited them to SF SVN or even dcommited whole local branches to SF SVN.

    Harald> Usual work flow with Git, AFAIK: If you receive a patch, which
    Harald> you don't trust, you can invite others to check it. They will
    Harald> pull this change set from your public repository. If everything
    Harald> looks fine, you send a pull request to the maintainer of the
    Harald> master, telling him, that this is a verified patch. The
    Harald> maintainer will pull it into his local repo, have a final look
    Harald> and then commit it to the public master repo.

With regard of releases, you always were the master. But during my time
contributing, I didn't see such a workflow or such a master for our SVN
HEAD. So to implement the workflow above, we would need a person to take the
role of such a master. If somebody intends to step in, a switch to git is
justified and needed.
But you restarted the discussion with the argument that SF is slow for "svn
log" . And this can be solved if you checkout SVN locally as git and use
"git log". And this doesn't justify a switch.

    Harald> Now, how does this work, if the SVN repo is our virtual "Git
    Harald> master"? Do all developers still have write access to the
    Harald> master? Is this virtual master the only way to distribute change
    Harald> sets among developers? If yes, isn't that annulling
    Harald> characteristic features that made Git so successful? Or are
    Harald> there better ways to handle it, which I'm too stupid to see?

I didn't suggest to make SF SVN a git master. I suggested to leave SF SVN as
it is with the argument that everybody may use his preferred RCS locally
without any impact on SF SVN.

But again, if you intend to use more advanced features and workflows for the
central repo and require others to obey new rules, a switch may be needed
and the workflow change has to be used by other contributors.

Regards

-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------