Git

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
jmaustpc
Posts: 9566
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: Git

Postby jmaustpc » Fri Dec 23, 2011 9:27 am

If anyone finds that all this pushing and pulling is inappropriate for their situation for whatever reason or just to difficult for some reason, that GIT is intended to work well with emailed diffs.

So one could still make a diff and email that to a developer for them comment on and commit etc..

So unless you three disagree with my comments above, I imagine you would be quite happy for someone to email you a diff? I thought there may be some who want to do so, particularly during the transition stage.


Jim
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Git

Postby jriegel » Fri Dec 23, 2011 10:17 am

Sure,
code is always welcome in any form!! :)
Stop whining - start coding!
wmayer
Site Admin
Posts: 14885
Joined: Thu Feb 19, 2009 10:32 am

Re: Git

Postby wmayer » Fri Dec 23, 2011 1:30 pm

If nobody disagrees then I would like to have SVN as the default VCS at least until mid of January. This is because there I have some free time and can use this for coding instead of wasting it by reading Git tutorials.
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Git

Postby jriegel » Fri Dec 23, 2011 1:57 pm

Sure! As I said, at the moment its no problem to use them both.
Stop whining - start coding!
User avatar
yorik
Site Admin
Posts: 11552
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Git

Postby yorik » Sat Dec 24, 2011 3:45 pm

I found this very good page that resumes important git stuff:
http://spheredev.org/wiki/Git_for_the_lazy

It looks like who's committing to SF git via ssh must use SF email, but the name must not be the SF username. Seems ok to me. Another cool tip they give is how to format nice commit messages:
The author of Pro Git (an excellent online book) gives this advice for commit messages:

Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. As a general rule, your messages should start with a single line that's no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation. The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior — this is a good guideline to follow. It's also a good idea to use the imperative present tense in these messages. In other words, use commands. Instead of "I added tests for" or "Adding tests for," use "Add tests for." Here is a template originally written by Tim Pope at tpope.net:

Code: Select all

    Short (50 chars or less) summary of changes

    More detailed explanatory text, if necessary.  Wrap it to about 72
    characters or so.  In some contexts, the first line is treated as the
    subject of an email and the rest of the text as the body.  The blank
    line separating the summary from the body is critical (unless you omit
    the body entirely); tools like rebase can get confused if you run the
    two together.

    Further paragraphs come after blank lines.

     - Bullet points are okay, too

     - Typically a hyphen or asterisk is used for the bullet, preceded by a
       single space, with blank lines in between, but conventions vary here
If all your commit messages look like this, things will be a lot easier for you and the developers you work with. The Git project has well-formatted commit messages — I encourage you to run git log --no-merges there to see what a nicely formatted project-commit history looks like.
This seems nice to me... We could adopt it as a rule, what do you think?
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Git

Postby jriegel » Sat Dec 24, 2011 4:35 pm

Looks good!
I would say yes!
Stop whining - start coding!
User avatar
tanderson69
Posts: 1500
Joined: Thu Feb 18, 2010 1:07 am

Re: Git

Postby tanderson69 » Sat Dec 24, 2011 7:15 pm

For what it is worth: While on feature branch, I would make as many commits large or small as makes sense for what you are working on using a short commit message. When you decide your done and want to merge, I would do a git log master..feature and use the output as a basis for your quality commit message. Then when you merge to master use --squash and commit with your quality commit message. This will allow you to be very liberal with your commits and not worry about polluting the master branch.
User avatar
yorik
Site Admin
Posts: 11552
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Git

Postby yorik » Sat Dec 24, 2011 8:25 pm

Good tip tanderson69... I didn't know about that squash option
User avatar
NormandC
Posts: 18534
Joined: Sat Feb 06, 2010 9:52 pm
Location: Québec, Canada

Re: Git

Postby NormandC » Mon Dec 26, 2011 11:05 pm

FYI,

I just requested a Git code import on Launchpad. It should be updated in the next hours/days.

https://code.launchpad.net/~freecad-mai ... eecad/head

And this one will be owned by the FreeCAD Maintainers team, not by the VCSImports group! So we'll have more control over it (I think). :)

Edit: OK that was fast, it's done already! :D All of you members of the FreeCAD Maintainers team should have received an automated email like 3 minutes ago.

And BTW: new numbering, Launchpad has detected only 344 revisions... :roll:
User avatar
yorik
Site Admin
Posts: 11552
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Git

Postby yorik » Tue Dec 27, 2011 1:28 am

normandc wrote:And BTW: new numbering, Launchpad has detected only 344 revisions... :roll:
That's normal I think... Jürgen imported only some of the latest SVN revisions into git, not all of them