Date: Thu, 25 Jun 2020 10:08:28 -0700 From: Sean Chittenden <sean@chittenden.org> To: Brooks Davis <brooks@freebsd.org> Cc: Ed Maste <emaste@freebsd.org>, freebsd-git@freebsd.org Subject: Re: svn primer translation to git Message-ID: <CAHevUJE-Es=8sw6zGioS-UuaQNhhkbGJZdG9hbsosS7ENYUY-g@mail.gmail.com> In-Reply-To: <20200625165547.GA75705@spindle.one-eyed-alien.net> References: <CAPyFy2Dy4cLQpgUsk_ushXsQFvRPk2S8SEfgWF=0xibGRGJvKw@mail.gmail.com> <20200625165547.GA75705@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> 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).
-sc
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHevUJE-Es=8sw6zGioS-UuaQNhhkbGJZdG9hbsosS7ENYUY-g>