On Thu, Nov 23, 2006 at 04:33:42PM +0000, Catalin Marinas wrote: > >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. Right, I do not discuss the behaviour of git here. But when I first encountered this issue, I was really wondering about what was happenning. It would be really helpful in such a case, if stgit was able to pinpoint the precise patch which could not be popped. It could also be helpful to tell when popping patches - currently it's done "behind my back", and I could only understand what was happenning by reading the code. > >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. I'm not sure if git itself should add support for this. IMHO, such an issue is more related to the nature of patch management - git itself does not have a need to repetedly pop/push paches, with related merge hassles like this one. > >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. Right, it could be advertised as good practice to burry those near the bottom of the stack, and anyway to keep actively-changing ones near the top. > >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? Hm, let's see... I'd say "export" (I have missed it already), "files" and maybe "commit" and "pick", although the latter would require a syntax for ranges in other branch. While reviewing the various commands for this, I realized that "stg pop <patch>" semantics is significantly different from "stg push <patch>" - ie. it is an equivalent of "goto". What about turning it into a float+pop, to better match the "push" behaviour ? I also realized that "stg help <command>" output does not go through to the pager, while eg. the help for "mail" is quite long. 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