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

Re: [PATCH 0/5] My set of stgit companion scripts.

From
CMCatalin Marinas <catalin.marinas@gmail.com>
Date
Jan 9, 2007, 10:21 UTC
Message-ID
<b0943d9e0701090221o6437fc0ana17bb190eb1eae0b@mail.gmail.com>
In-Reply-To
<20070104233934.13580.17744.stgit@gandelf.nowhere.earth>
On 04/01/07, Yann Dirson <ydirson@altern.org> wrote:
> The following series adds to contrib/ a set of bash scripts I find useful
> for my daily use of stgit.  They are probably closely tied to my workflow,
> but others may find them useful as well.  Some of them may be useful to
> pythonize and integrate in some form or another.

Yes, indeed. I'll try this week (now that the holidays are finished) to add TODO and wishlist pages on the wiki so that people can extend them.

> stg-show-old is a trivial thing, but since I often need that functionnality,
> it is much less comfortable than forging the same command-line over and over
> again.  It is also used by some of the other scripts.

Since we have some kind of patch history support, I'd rather extend the git_id() function to parse patch names appended with ^ or ~x as in GIT. This way you can access the full history and not only the previous version of the patch.

You can currently do 'stg show [<patch>]//top.old'
> stg-fold-files-from and stg-swallow are invaluable when shuffing changes
> between patches.

The first one is indeed useful and might not be easy to implement in a python-only script. The latter is useful as a shortcut but I would rather have a python command (or --swallow option to 'pick' in addition to --fold) to automate this.

> stg-what-changed is invaluable when shuffling patches in the stack.

It's interesting to see the diff of diffs but it takes some time to get used to it :-). There is 'stg log (--patch|--graphical)' which shows the diff of every refresh you did on the patch. What it doesn't show is the diff of a push since this creates a new patch version every time. Maybe this could be extended so that for push with conflicts, it first stores a version with conflict markers and another version after fixing them and refreshing.

> stg-cvs is a very young script, and probably very fragile.  It allows a
> lightweight way of preparing changes with stgit before committing them into
> a CVS tree.
I'm OK with this (but I won't use it much).
Thanks.
-- 
Catalin
Previous: Yann DirsonNext: Yann Dirson
Message 7 of 8 in “My set of stgit companion scripts.”
  1. 0/5 My set of stgit companion scripts.Yann Dirson, Jan 4, 2007
  2. 1/5 Add contrib/stg-show-old: show old version of a patch.Yann Dirson, Jan 4, 2007
  3. 2/5 Add contrib/stg-whatchanged: look at what would be changed by refreshing.Yann Dirson, Jan 4, 2007
  4. 3/5 Add contrib/stg-fold-files-from: pick selected changes from a patch above current oneYann Dirson, Jan 4, 2007
  5. 4/5 Add contrib/stg-swallow: completely merge an unapplied patch into current oneYann Dirson, Jan 4, 2007
  6. 5/5 Add contrib/stg-cvs: helper script to manage a mixed cvs/stgit working copyYann Dirson, Jan 4, 2007
  7. Catalin MarinasJan 9, 2007
  8. Yann DirsonJan 9, 2007

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.