On Sun, May 7, 2017 at 11:26 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Samuel Lijin <sxlijin@xxxxxxxxx> writes: > >> 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. Got it - will keep this in mind when I reroll the patch series. >> 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"? The latter, as I believe you noticed in your reply about patch 9/9. What happens right now is that because (1) directories containing only untracked and ignored files are considered "untracked" and (2) read_directory_recursive() skips over untracked directories, even with DIR_SHOW_IGNORED_TOO set. As a result, `status --ignored` never lists ignored files if they're in an "untracked" directory (and this is the currently defined behavior per t7061). By teaching read_directory_recursive() to recurse into untracked directories in search of ignored files when DIR_SHOW_IGNORED_TOO is set, though, `status --ignored` now learns to report the existence of these ignored files, whereas previously it did not. >> 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. Aha - thanks.