git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
PRPavel Roskin <proski@gnu.org>
Date
Jan 20, 2006, 06:23 UTC
Message-ID
<1137738224.27911.26.camel@dv>
In-Reply-To
<20060119213838.GA27397@nowhere.earth>
On Thu, 2006-01-19 at 22:38 +0100, Yann Dirson wrote:
Show 7 quoted lines
> > 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.

Show 5 quoted lines
> 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
Previous: Yann DirsonNext: J. Bruce Fields
Message 10 of 19 in “StGIT: "stg new" vs "stg new --force"”
  1. Pavel RoskinJan 13, 2006
  2. Karl HasselströmJan 13, 2006
  3. Catalin MarinasJan 16, 2006
  4. Pavel RoskinJan 17, 2006
  5. Yann DirsonJan 17, 2006
  6. Pavel RoskinJan 17, 2006
  7. Yann DirsonJan 18, 2006
  8. Pavel RoskinJan 19, 2006
  9. Yann DirsonJan 19, 2006
  10. Pavel RoskinJan 20, 2006
  11. J. Bruce FieldsJan 20, 2006
  12. Pavel RoskinJan 24, 2006
  13. J. Bruce FieldsJan 24, 2006
  14. Pavel RoskinJan 24, 2006
  15. Catalin MarinasJan 24, 2006
  16. Catalin MarinasJan 21, 2006
  17. Pavel RoskinJan 22, 2006
  18. Catalin MarinasJan 21, 2006
  19. Catalin MarinasJan 21, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.