Date: Thu, 25 Jun 2020 11:47:24 -0600 From: Warner Losh <imp@bsdimp.com> To: Brooks Davis <brooks@freebsd.org> Cc: Sean Chittenden <sean@chittenden.org>, freebsd-git@freebsd.org Subject: Re: svn primer translation to git Message-ID: <CANCZdfow92K_a-60VyzhkkCMg7MjXfJz1zwSisGTT1qdTCD31g@mail.gmail.com> In-Reply-To: <20200625171314.GB75705@spindle.one-eyed-alien.net> References: <CAPyFy2Dy4cLQpgUsk_ushXsQFvRPk2S8SEfgWF=0xibGRGJvKw@mail.gmail.com> <20200625165547.GA75705@spindle.one-eyed-alien.net> <CAHevUJE-Es=8sw6zGioS-UuaQNhhkbGJZdG9hbsosS7ENYUY-g@mail.gmail.com> <20200625171314.GB75705@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 25, 2020 at 11:13 AM Brooks Davis <brooks@freebsd.org> wrote:
> 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.
>
I almost always do a git show for each and every commit I push. The few
times I've tried to short cut this, I've wound up in trouble.
I also am a big believer in git rebase -i and git commit --amend to curate
the commits I'm going to push in. The more you can show people how to
double check the commit, fix what's broken, etc, the better off we'll be.
And the better off people will be since they will have more tools to
un-screwup something they did by mistake. Unlike svn, rewriting history
(especially local history) is a big feature.
I use git commit -a all the time, though, since I hate git add. But only
when I'm sure that's the right thing and I have enough checks and balances
in place with the curation process I can do that). I agree, we should
recommend against it. Since I also know how to un-footshoot w/o it being a
traumatic web search and anxiety ridden typing of git commands blind,
hoping for the best....
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfow92K_a-60VyzhkkCMg7MjXfJz1zwSisGTT1qdTCD31g>