[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gits] Git commit formatting and git mail about public repositories. Was [Re: git commit: [emulab-dreading] branch master updated (7024b54)]
- Subject: [gits] Git commit formatting and git mail about public repositories. Was [Re: git commit: [emulab-dreading] branch master updated (7024b54)]
- From: dreading at flux.utah.edu (Dan Reading)
- Date: Thu, 27 Jun 2013 08:32:14 -0600
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:
> 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
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
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,