mootools php faith camera linux


git commit Argument

There are three topics, but they all tie in together under the discussion of commiting code and making good commit messages.


git commit $x (bad!)

In this situation most coders would (if with a laugh) quickly type dot (.) or dash-a (-a) if a situation warranted its positive use. However, in most all cases, these are considered bad practice:

    git commit -a git commit . git commit *.*

Here is a common standard for committing code:

git add -p; git commit;

  • git add -p; (followed by)
  • git commit;

This is a wise method for committing code.
the "add -p" segment affords programmers a final chance to look out for "gotchas" like "error_log(oops)"



252321 Merge branch 
80c402 Merge branch 'feature-7121-replace_app_community_call-2' into stage
2aeb9a fix the total update
4f134e also update the cart
.total on pfsweb tax/shipping calculation
840c0d cart_payment
.received is supposed to be the ammount we "received" which is best represented for paypal in the PAYMENTINFO_0_AMT from the response

The excerpt shows 5 commit messages, above in bullets. We'll come back to those in a minute.

In vim, the commit message can be color coded. The text color changes when the message length nears 79 characters...and then it turns red...showing the commit msg creator that he or she hath typed too far!).

One of the many good reasons to keep it under 79 is to make the log show up well formatted *and* to provide more room for programmers to show other debugging tricks or notes or even snippets of code that you just weren't sure or maybe even wished there had been a chance to ask someone about, even short comments about how the code should or shouldn't run. One or two lines usually will suffice.

Let's are (79 characters) and then the (commit msgs) after the single, blank line.:

79 characters vs length of commit messages

Merge branch 
'stage' (*252321*)
Merge branch 'feature-replace-tax-call' into stage

Fixed the total update
Also updated the cart
.total on client's tax/shipping calculation
cart_payment.received is supposed to be the ammount we "received" which is best represented for filling the AMT_0 element in the response

So we can have our cake and eat it too. Make the commit message 79 or fewer characters, while providing a great bit more detail without ruining the output of `git log`.


When making the `git commit` call (after completing hunks adding with `git add -p`), the vim editor launches, and we begin typing, perhaps a commit msg like this:

-some-complex-stuffadded filtering column

There was a problem with the filtering of the report
here is an example urlhttp://foo

What i tried to do was use the actions data to solve it.
Insteadi ended up just putting a column in the database
so i could filter the report using other magic

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch stage
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#   new file:   asdf
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)

In the end, the point is to create a git log that tells a clear story to anyone reading it. Using `git add -p` and `git commit` (without the -m) are the first steps in that direction.

Last Updated: 2013-08-08 19:46:34
Creative Commons License Jay Johnston is a Zend Certified Engineer in PHP 5 LPI-ID: LPI000102450, Verfication Code: wmnnt56y2k  ... Jay Johnston is certified as LPIC-1 by the Linux Professional Institute