On 23/11/06, Yann Dirson <ydirson@xxxxxxxxxx> wrote:
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.
That's a git error and I think it is the correct behaviour. It is safer to notify that a local file is overridden by a merge/switch operation rather than just losing its content.
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".
Maybe 'stg clean' should only pop to the first empty applied patch rather than popping all of them as it is also more efficient.
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).
That's a GIT issue more than an StGIT one, unless GIT already has a way to deal with this and StGIT doesn't pass the right options.
First, when cleaning patches, we could first look up which patches are to be removed, and only pop the necessary ones.
OK, I mentioned it above as well. This should really be done for efficiency but it might not solve the problem if the empty patch is deeper into the stack.
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".
Easy to fix as well.
BTW, maybe it would those make sense to allowthose special ranges in most places a range is valid.
Is there any other place where ranges could be used but aren't? -- Catalin - 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