I recently encountered a problem with "stgit clean", but it really is a generic issue, which can also impact other subcommands. In a kernel tree, the precise problem I had is due to generated files committed by error in an upstream branch (a BSP from a well-known vendor, indeed ;). The first patch in my stgir stack does some cleanup by removing them from git control (so that "make dep" does not cause them to change every so often). Now when I want to run "stg clean" for applied patches, stgit first wants to pop the whole stack, including that patch, which triggers the following error: fatal: Untracked working tree file 'include/asm-arm/constants.h' would be overwritten by merge. stg clean: git-read-tree failed (local changes maybe?) Obviously, removing all such files by hand allows to run "stg clean", as does (floating and) popping that patch and deleting it, or running "stg clean --unappplied". The 1st approach is intrusive, and forces the user to rerun "make dep", which is not very friendy; the 2nd one is too error-prone for an operation that ought to be risk-less (delete has no --undo). The 3rd option is probably the best, but is surely not so intuitive. The root issue seems to be that stgit has problem with such generated files, ie., files that were removed from version-control, but can still legitimately exist in the tree. Dealing with them could possibly be done (eg. allowing to back them up, and restore them when pushing the annoying patch), but is not a trivial issue (eg. we still need to guard the user against real conflicts). At least we could put a notice about this case in the doc, so users don't get too surprised. I could think of several (non-exclusive) possibilities to deal with the precise problem I got, which should allow. First, when cleaning patches, we could first look up which patches are to be removed, and only pop the necessary ones. Second, we could generalize the "clean" subcommand to accept arbitrary ranges, not only the "applied" and "unapplied" ones. A special case would be "stg clean that-patch", which would be a secure version of "stg delete". BTW, maybe it would those make sense to allowthose special ranges in most places a range is valid. Best regards, -- Yann. - 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