[gits] Git commit formatting and git mail about public repositories. Was [Re: git commit: [emulab-dreading] branch master updated (7024b54)]

[dreading at flux.utah.edu (Dan Reading)]

On Wed, Jun 26, 2013 at 5:42 PM, Eric Eide <eeide at cs.utah.edu> wrote:
>         Dan> Branch master has been updated: 6875599..7024b54
>         Dan>  - remove check for gather arg, use TESTINFO from tmcc hwinfo instead. O
>         Dan>  - tmcc hwinfo not return a TESTINFO line. Handel the LOGDIR, COLLECT an
>         Dan>  - Do to variable scoping make sure everthing runs in the shell. Do not
>         Dan>  - Nothing wrong with the which() function I put in since the MFS/busybo
>         Dan>  - output format changes and programming space changes
>         Dan>  - Merge branch 'master' of git-public.flux.utah.edu:/flux/git/users/dre
>         Dan>  - try harder to get ntpserver
>         Dan>  - change bash 4 check, change BINDIR check
>         Dan>  - call sub-progams by source not new shell.
>         Dan>  - minor output format change - add date
...
> ... let me suggest that you consider
> this popular advice for writing "good" git commit messages:
>
>   http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
>
> In particular, if you adopt the convention:
>
>   + 1st line: A short, one-line summary of the whole commit.
>   + 2nd line: [Blank line]
>   + Rest:     The detailed summary.
>
> Then your commit messages will be easy to understand in git log views.

Let me remark on my commit message usage. This date back to RCS days.
I try to commit on a regular basis.
1) If I've just finished a change and its working.
2) If I'm about to try something new and want to be able to fall back
to a earlier state. There maybe many types of #2 between #1s.

I try make my change sets as independent as possible checking in all
the files related to that change in one commit (CVS days).  With #2
type commits I regularly use the -m option since the change is usually
well confided and can be documented in a single line. In theory the
change could be removed later without breaking the code.
I've also started using 'git add -p' to further separate disjointed
changes.

With git I've been using 'git push' for the #1 type of commit. So in
regards to the above git 'update' message, it spans 10 commits each
with a "A short, one-line summary of the whole commit." and no
detailed summary.

The 'git update' mail message is further made to look non-concise when
my 'public' repository is pushed to the central repository and every other
earlier push message is basically repeated.

----

So a question arises for me: Why send mail about git pushes into
'public' repositories, specially when one is not collaborating with
anyone else using that 'public' repository?

Second thought, when 'pushing/rebasing' my public repository to
central is it possible to bundle all the separate commit message into one,
with a summary line and the individual commit messages for the
detailed documentation. Is this where a branch comes into play?

Thanks for any comments,

-- 
Dan