Re: RFC: Moving to github

Uwe Bonnes <bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org>
Newsgroups gmane.comp.hardware.microcontrollers.ethernut
Message-ID <[email protected]>
>>>>> "Harald" == Harald Kipp <[email protected]> writes:


    Harald> Several contributions to this list suggested to switch to Git,
    Harald> but keep the SVN workflow. In the meantime my experience is,
    Harald> that this is the worst of both world.

Can you tell about your experience? What is worse?

    Harald> What I like with SVN is its simple revision structure and how it
    Harald> keeps track about patches between branches. However, Uwe
    Harald> reported problems with SVN merging, when using Git with SVN. See

    Harald> http://comments.gmane.org/gmane.comp.hardware.microcontrollers.ethernut/14643

Well, probably I barked to early at that time.

" git log -p --follow nut/gorp/edit/edline.c" at least shows the changes.

And I was in the missbelief that "git svn fetch" also fetches the changes in
branches. I now noticed that this is not true. Probably if I fetch and
rebase devnut-tiva, "git log" will even have more info about the
merge. As long at the local git repo doesn't have 5894-r5896, it can't tell
about the commit messages doen with r5894-r5896.But probably will show the
commit messages, when I have fetched r5894-r5896 in the local git
repo.However with the present SF downtime, I can not check.

    Harald> The solution he suggested makes "svn mergeinfo" completely
    Harald> useless and cherry picking and tracking of trunk patches for
    Harald> older branches too time consuming. As a result, the 4.x branches
    Harald> were no longer maintained since then and SVN lost one of its
    Harald> essential features.

So did my nitpicking keep you from updating the 4.x branches? Sorry about
that!

    Harald> The thing I like most with Git is its decentralized workflow.

    Harald> Several posts to this list suggested the centralized workflow,
    Harald> but IMHO this would limit Git's most prominent feature,
    Harald> decentralization.

Well, everybody working on SVN is now cut off:
- No patch history
- No way to check in local changes.
Somebody working with git-svn can still:
- check in patches to his local tree
- look at the patch history of file
- branch, etc.

That is some very important decentralization!

    Harald> So, if you want to lose essential features of SVN and Git, then
    Harald> continue to emulate SVN with Git. If you want get the full
    Harald> potential of Git, then I'd strongly recommend to use the forking
    Harald> workflow. Once again I'd like to point you to

I think git-svn doesn't emulate SVN with Git. I only makes the SVN repo
accessible in the git way, without changing the SVN repo as such.

Of cource, I fork. But I only fork in my local repo, and I soon resync with
the central repo.

So again, please elaborate where this is "the worst of both world".

Bye
-- 
Uwe Bonnes                bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.