[FFmpeg-devel] Git short walkthrought Was: [GIT] ready by the weekend
Wed Dec 15 01:09:35 CET 2010
On Fri, Dec 10, 2010 at 10:33 AM, Luca Barbato <lu_zero at gentoo.org> wrote:
> On 12/1/10 3:44 PM, compn wrote:
> Some more changes.
> I'm thinking to add a section about using topic branches (on github or
> gitosis) to the developer.html if you all agree.
IMO that's a good idea.
> 7. Committing:
> git diff --check
> to doublecheck your changes before committing them to avoid trouble later
> on. All experienced developers do this on each and every commit, no matter
> how small.
> Every one of them has been saved from looking like a fool by this many times.
> It's very easy for stray debug output or cosmetic modifications to slip in,
> please avoid problems through this extra level of scrutiny.
> For cosmetics-only commits you should get (almost) empty output from
> git diff -wb <filename(s)>
> Also check the output of
> git status
> to make sure you don't have untracked files or deletions.
> git add [-i|-p|-A] <filenames/dirnames>
> Git will select the changes to the files for commit. Optionally you can use
> the interactive or the patch mode to select hunk by hunk what should be
> added to the commit.
Could you elaborate more on those modes?
> git commit
> Git will commit the selected changes to your current local branch.
> You will be prompted for a log message in an editor, which is either
> set in your personal configuration file throught
> git config core.editor
> or set by one of the following environment variables:
> GIT_EDITOR, VISUAL or EDITOR.
> Log messages should be concise but descriptive. Explain why you made a change,
> what you did will be obvious from the changes themselves most of the time.
> Saying just "bug fix" or "10l" is bad. Remember that people of varying skill
> levels look at and educate themselves while reading through your code. Don't
> include filenames in log messages, Git provides that information.
> Possibly make the commit message have a terse, descriptive first line, an
Why "possibly"? Could we make this a rule?
> empty line and then a full description. The first line will be used to name
> the patch by git format-patch.
> 11. Sending patches for review
> git send-email <commit list|directory>
> will send the patches created by git format-patch or directly generates
> them. All the email fields can be configured in the global/local
> configuration or overridden by command line.
More information on how to configure for ffmpeg-devel would be nice.
> 12. Pushing changes to remote trees
> git push
> Will push the changes to the default remote (origin).
> Git will prevent you from pushing changes if the local and remote trees are
> out of sync. Refer to 2 and 2.a to sync the local tree.
> git remote add <name> <url>
> Will add additional remote with a name reference, it is useful if you want
> to push your local branch for review on a remote host.
> git push <remote> <refspec>
> Will push the changes to the remote repository. Omitting refspec makes git
> push update all the remote branches matching the local ones.
> Contact the project admins <root at ffmpeg dot org> if you have technical
> problems with the GIT server.
Shouldn't that be the videolan admins? Who is root at ffmpeg.org nowadays?
More information about the ffmpeg-devel