Re: StGIT: "stg new" vs "stg new --force"

[Pavel Roskin <proski@gnu.org>]

On Thu, 2006-01-19 at 22:38 +0100, Yann Dirson wrote:
> > I believe StGIT should be primarily designed to be used interactively.
> 
> I tend to disagree.  3rd-party apps like qgit should be able to let
> the user do the selection, and tell the command-line tool what they
> want to act upon.  It may be useful as well if stg gains
> interactivity, but should not become the only way to work with it
> (unix way of life).

In this particular case, the GUI frontend should be able to supply much
more data than the hunk numbers.  It would be much safer.

I didn't mean to say that StGIT shouldn't have any options for
non-interactive processing.  I meant that whenever adding a feature, we
should try to make it immediately useful without any frontends or
additional software.

> Maybe we could have a "fold" or "refresh" variant that takes its
> output from the output of "stg diff" (or any arbitrary diff on stdin,
> to be friendly with GUI wrappers) filtered by an arbitrary command.

That would be "fold".  "refresh" like is saying - this patch should
produce this file.  I actually tend to think now that deep refresh would
be confusing and dangerous if there is another patch closer in the stack
working with the same file, even in a separate part of it.  stg would
either report conflict with the higher patches use the file with the
higher patches reverted, and neither sounds good to me.

Deep fold of the local changes would be much easier, since no other
patch should have them.

> That command could be "cat" to get the current "refresh" behaviour, or
> an editor wrapper acting on stdin/out, or a wrapper to filterdiff, or
> whatever clever filter one would want to use.
> 
> Does it sound better ?

Yes.  The first step would be to fix "stg refresh --edit --showpatch" to
actually respect edits made to the patch.

-- 
Regards,
Pavel Roskin