Git

[jmaustpc]

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

[jriegel]

Sure,
code is always welcome in any form!!

[wmayer]

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.

[jriegel]

Sure! As I said, at the moment its no problem to use them both.

[yorik]

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?

[jriegel]

Looks good!
I would say yes!

[tanderson69]

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.

[yorik]

Good tip tanderson69... I didn't know about that squash option

[NormandC]

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

[yorik]

And BTW: new numbering, Launchpad has detected only 344 revisions...

That's normal I think... Jürgen imported only some of the latest SVN revisions into git, not all of them