[FFmpeg-devel] Git short walkthrought Was: [GIT] ready by the weekend

[Ramiro Polla]

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:
> [snip]
>
> 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?