Git
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Git
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
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
Re: Git
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.
Re: Git
Sure! As I said, at the moment its no problem to use them both.
Stop whining - start coding!
Re: Git
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:
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:
This seems nice to me... We could adopt it as a rule, what do you think?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:
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.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
- tanderson69
- Veteran
- Posts: 1626
- Joined: Thu Feb 18, 2010 1:07 am
Re: Git
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.
Re: Git
Good tip tanderson69... I didn't know about that squash option
Re: Git
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...
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...
Re: Git
That's normal I think... Jürgen imported only some of the latest SVN revisions into git, not all of themnormandc wrote:And BTW: new numbering, Launchpad has detected only 344 revisions...