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

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Nov 23, 2006, 16:33 UTC
Message-ID: <b0943d9e0611230833y5ffc14d3q922a821744ad05d@mail.gmail.com>
In-Reply-To: <20061123161135.GK5443@nan92-1-81-57-214-146.fbx.proxad.net>

On 23/11/06, Yann Dirson <ydirson@altern.org> wrote:

Show 11 quoted lines

> 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.

Show 6 quoted lines

> 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?