Re: "stgit clean" has problems with removed generated files

On 23/11/06, Yann Dirson <ydirson@altern.org> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html