On Mon, Feb 08, 2016 at 05:36:50PM -0500, Matt McCutchen wrote: > On Mon, 2016-02-08 at 14:22 -0800, Junio C Hamano wrote: > > Matt McCutchen <matt@xxxxxxxxxxxxxxxxx> writes: > > > > > I found no evidence of such behavior in the source code. > > > > > > Signed-off-by: Matt McCutchen <matt@xxxxxxxxxxxxxxxxx> > > > --- > > > > That was added last year at bcd57cb9 (Documentation/git-clean.txt: > > document that -f may need to be given twice, 2015-02-26). It would > > be better to know what got changed since then--that is, was the > > additional text unnecessary even back then, or we made changes to > > the system since then and forgot to remove the added text. > > > > Mikko, is this need to give -f twice still the case? > > I know you probably want confirmation from Mikko, but I'll offer my > understanding. There were two statements added in bcd57cb9: > > 1. -f may need to be given twice to delete nested worktrees and > embedded repositories. This is still true. > > 2. Deletion of submodule repositories under .git/modules is conditional > on -f being given twice. AFAICT, this was wrong even back then: "git > clean" has never deleted such repositories under any conditions. This is the use case which I've used double -f at work with several build jobs but with older 1:1.7.9.5-1ubuntu0.2 (Ubuntu 12.04) and 1:1.9.1-1ubuntu0.2 (Ubuntu 14.04) versions of git. But I can confirm that git version 1:2.7.0~rc3-1 (Debian unstable) is no longer removing the git submodule trees from .git/modules with double -f. At work, we really want to remove the .git/modules subtrees since we want to test changes to .git/modules structure via normal commits to the git trees. Thus we need a way removing all non-tracked files from the git tree which includes obsolete (or for test only) git submodule trees. I will test the old versions tomorrow again. Maybe in older git versions the code path from 1) deletes also the git modules from 2). -Mikko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html