git workflow draft

John Layt johnlayt at
Wed Feb 16 12:58:48 GMT 2011

On Tuesday 15 February 2011 18:32:29 John Layt wrote:
> Actually, even more complete minutes, outstanding issues and action points
> can be found at

Following up on my action points for the commit template and config settings.

I've attached a revised commit template below.  The suggestion is for this to 
be added to each project repo in the root folder to allow for easy 
distribution and updating.  It would also allow each project to customise it 
as required, e.g. add links to projects own commit policy, extra tags, etc.

With regards to recommended git config settings, we could set the repo 
defaults in .git/config to include things like the kde: shortcuts, the commit 
template, and possibly push.default none.  Do we want to do this?  It would 
mean fewer steps required by a dev to set up their environment, and they can 
be changed by more skilled devs who don't want them (I'm assuming a locally 
modified .git/config doesn't get updated from the remote after the initial 
clone).  Any drawbacks?

I want to make a start on some of the Git recipe and reference documentation 
as things occur to me, and was thinking a central hub page leading off to the various 
tutorial, policy, recipe, sysadmin, etc pages would be a good idea.  Sound OK?



# ---[ You MUST wrap all lines at 72 characters ]----------------------|
# ---[ Please see ]-----|
# ===[ Subject ]=======================================================|
# ---[ One line only, short meaningful description to show in logs ]---|

# ---[ Leave following line blank, do NOT remove ]---------------------|

# ===[ Details ]=======================================================|
# ---[ Describe what has changed and explain why it has changed ]------|

# ===[ Fields ]========================================================|
# ---[ Uncomment and edit as applicable ]------------------------------|

# ---[ Add Feature to release changelog ]
# ---[ Optionally close a wish in as implemented ]
#FEATURE: <optional bug number>
# ---[ Close a bug in as fixed, with optional version ]
#BUG: <bug number>
#FIXED-IN: <release version>
# ---[ Copy commit message to a bug in ]
#CCBUG: <bug number>
# ---[ Copy commit message to an email address ]
#CCMAIL: <email>
# ---[ Close a review in as submitted ]
#REVIEW: <review number>
# ---[ Advise documentation team of user visible changes in the gui ]
# =====================================================================|

More information about the kde-core-devel mailing list