Re: [PATCH v2 0/9] Keep git clean -d from inadvertently removing ignored files

From: Junio C Hamano <gitster@pobox.com>
Date: May 8, 2017, 04:26 UTC
Message-ID: <xmqqh90w9do7.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170505104611.17845-1-sxlijin@gmail.com>

Samuel Lijin <sxlijin@gmail.com> writes:

Show 6 quoted lines

> Addresses the issues raised by Stefan and Junio (thanks for your
> feedback) about not using C99-style comments and keeping tests
> working on every commit to prevent breaking git bisect. (About the
> latter one: is it necessary to prevent compiler warnings, in
> addition to compiler errors? Because if so I should probably
> squash some of the commits together.)

Some of us build with -Werror, so yes. If by "squashing" you mean "instead of piling a fix on top of a broken patch, I need to do things right from the beginning", then yes, please do so, not just for compiler warnings but for all forms of changes.

> Note that this introduces a breaking change in the behavior of git
> status: when invoked with --ignored, git status will now return
> ignored files in an untracked directory, whereas previously it
> would not.

What do you mean by a "breaking change"? Is it just "a new bug"? Or "the current behaviour is logically broken, but people and scripts might have relied on that odd behaviour and fixing it this late in the game would break their expectations"?

Show 5 quoted lines

> It's possible that there are standard practices that I might have
> missed, so if there is anything along those lines, I'd appreciate
> you letting me know. (As an aside, about the git bisect thing: is
> there a script somewhere that people use to test patch series
> before sending them out?)

I hear that people use variations of

    git rebase -x "make test"

on their topic.