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 19, 2006, 00:49 UTC
Message-ID
<1137631749.13853.22.camel@dv>
In-Reply-To
<20060118193717.GI32585@nowhere.earth>
On Wed, 2006-01-18 at 20:37 +0100, Yann Dirson wrote:
Show 19 quoted lines
> > > It would even be useful sometimes to dispatch changes to a single file
> > > into several patches.  When they are distinct enough to be in
> > > different diff hunks, it is pretty easy to split an existing patch,
> > > but it could also be useful to only refresh a patch with specific diff
> > > hunks.  A possibility would be to add a filterdiff-like "-#<n>" flag,
> > > in addition to the above-suggested "refresh <file>" (and possibly only
> > > allow to specify a single file together with this flag).
> > 
> > I think if would be better to improve "stg fold" to work on arbitrary
> > patches.  This way, you prepare the patch in the editor (which would not
> > be harder than finding hunk numbers) and fold it into the patch of your
> > choice.  stg should check that the stack remains valid, possibly doing
> > trivial adjustments to the higher patches.  The current tree should not
> > be impacted.
> 
> This sounds like a good idea as well (and I would use it on a near
> daily basis as well ;).  Obviously such a request can also fail,
> eg. when requesting to fold a change into a patch, where a subsequent
> patch modifies the same lines.
Definitely.  Hard cases should be handled by hand.
> But it would not be a replacement to selecting changes with a
> granularity finer than file-level, which is what I wanted to suggest.

Why? Maybe you got confused by two meanings of the word "patch"? I think StGIT should use some other term, e.g. changeset. I meant that the diff file (e.g. made by "stg diff") could be edited and folded into one of the StGIT patches (changesets). Unless you want non-interactive separation of the hunks, using an editor should be a reasonable approach.

I believe StGIT should be primarily designed to be used interactively. Your approach looks like a usability disaster to me. The user is supposed to find numbers of the hunks, although s/he is working on the whole file (since it's "stg refresh").

My approach suggests that the user work with the diff from the beginning, and separates the changes by looking at them.

-- 
Regards,
Pavel Roskin
Previous: Yann DirsonNext: Yann Dirson
Message 8 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.