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

Re: [StGit PATCH] edit: Allow setting git tree SHA1 of a patch

From
GHGustav Hållberg <gustav@gmail.com>
Date
May 21, 2010, 15:32 UTC
Message-ID
<AANLkTimYCxzT16aI96dztmcKYuVrvKikSkrkRHT-Ckcd@mail.gmail.com>
In-Reply-To
<AANLkTilV3VQARdyZ-m9GCXz1Rwt0j6Q6noNyFrmmDzR5@mail.gmail.com>
Show 9 quoted lines
> On 21 May 2010 14:59, David Kågedal <davidk@lysator.liu.se> wrote:
>> The idea is that Gustav wants to allow the editing of a file as it
>> appears in an earlier version. Lets say you have patches A, B, C and
>> D. You realize that one of the changes in to foo.c in C shuold really be
>> done in A. So you open the "A version of foo.c" in your editor, do the
>> change, and then save it. The save operation needs to update A to be
>> the new tree that contains the updated foo.c, and the remaining patches
>> will keep their tree. The effect is that the moved change now appears as
>> a diff in A, but not in C (nor B or D).

David's example does not exactly describe the situation I have in mind. I was only envisaging the possibility to move a change from one patch to one of its neighbours. This is enforced by keeping all other trees intact.

On Fri, May 21, 2010 at 5:16 PM, Catalin Marinas <catalin.marinas@gmail.com> wro> This is currently achieved by "pop B C D", edit file, "refresh", "push

Show 5 quoted lines
> --set-tree B C D".
>
> Can "edit --set-tree <sha1>" make this simpler? Which <sha1> value
> would be used with "edit --set-tree" (unless that's done by Emacs mode
> behind the scene and it generates the tree that gets passed to edit).

This is indeed my assumption. Without a "smart" user interface to hide the intricacies this operation becomes too complicated. At least unless you work exclusively with the index. My prototype for the Emacs mode approximately does 'read-tree <old patch sha1>', 'update-index --cache-info <new blob>', 'stg edit --set-tree $(write-tree)'.

I actually think it is the use of the Emacs user interface that really enabled us (me and my colleagues) to see the stack as a living set of changes that are very easy to edit. This lead to the conclusion that one wants to make it much easier, light-weight and faster to move individual changes between (for a start, neighbouring) patches.

As you point out, there are a number of ways to do these things already; this is all about making it very easy.

- Gustav
Previous: David KågedalNext: Catalin Marinas
Message 7 of 16 in “edit: Allow setting git tree SHA1 of a patch”
  1. edit: Allow setting git tree SHA1 of a patchGustav Hållberg, May 16, 2010
  2. Karl WibergMay 17, 2010
  3. Catalin MarinasMay 21, 2010
  4. David KågedalMay 21, 2010
  5. Catalin MarinasMay 21, 2010
  6. David KågedalMay 21, 2010
  7. Gustav HållbergMay 21, 2010
  8. Catalin MarinasMay 21, 2010
  9. David KågedalMay 21, 2010
  10. Gustav HållbergMay 21, 2010
  11. 0/2 Setting git tree of a patch (improved version)Gustav Hållberg, May 24, 2010
  12. 1/2 Repository.rev_parse: support commits, trees, and blobsGustav Hållberg, May 24, 2010
  13. 2/2 edit: Allow setting git tree of a patchGustav Hållberg, May 24, 2010
  14. Catalin MarinasMay 25, 2010
  15. Gustav HållbergMay 26, 2010
  16. Catalin MarinasMay 26, 2010

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.