svn primer translation to git

Brooks Davis brooks at
Thu Jun 25 17:13:15 UTC 2020

On Thu, Jun 25, 2020 at 10:08:28AM -0700, Sean Chittenden wrote:
> >
> > generally follow a process of staging with `git add -p` + `git add` for
> > new files followed by `git status` and/or `git diff --staged`, and then
> > `git commit`.
> >
> This is a good callout, Brooks.
> I'm routinely shocked by the number of people who don't know about or use
> `git add -p` as their muscle-memory way to add something to a commit.  We
> definitely should go out of our way to document best practices.  For
> instance, this has been the workflow that I've worked in or pushed teams to
> for the last 6yrs and have had decent success:
> 1. Create Github issue
> 2. git checkout -b gh-${issue_number}
> 3. git add -p
> 4. git status
> 5. git diff --staged
> 6. git commit
> 7. git push -u origin gh-${issue_number}
> Where `gh-` would be whatever bug-tracking system of choice that you fancy,
> but it keeps branch naming concise and gives the future reader a hint as to
> where to look for discussion.  While there may be variants of this, we
> should begin to prescribe a consistent workflow that does not encourage
> `git commit -a -m "fixedit"` or committing directly to main (svn's fka
> trunk branch).

One practice I've not adopted that we may want to recommend (especially
if we're going to have pre-commit scripts for people to install) is to
make your origin use a read-only url so you have to make an explicit
push to (e.g.) a freebsd remote.  At least at the beginning when it
appears we're going to be allowing direct commit, that's a way to
limit foot shooting.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <>

More information about the freebsd-git mailing list