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

Re: [RFC] undo and redo

From
KBKirby C. Bohling <kbohling@birddog.com>
Date
Aug 25, 2005, 20:49 UTC
Message-ID
<20050825204930.GE7461@birddog.com>
In-Reply-To
<7vmzn5vkg6.fsf@assigned-by-dhcp.cox.net>
On Thu, Aug 25, 2005 at 01:19:05PM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> "Kirby C. Bohling" <kbohling@birddog.com> writes:
> 
> > I guess my final question is what does undo/redo have over saving
> > stuff away in a patch assuming that the patch captures all of the
> > SCM meta-data (the add/move/remove file type commands).  If git
> > doesn't capture all the meta-data in a patch, it would seem better
> > to make it do that and get this as a side-affect.
> 
> One thing that Carl's undo saves that is not easily available in
> the patch form is the "what is this patch based on" information.
> If you had it, you could do a three-way merge instead of patch
> application.
Show 24 quoted lines
> You were at A (time flows from left to right) when somebody
> (maybe your bright idea) interrupted you.  You take a snapshot
> of your tree state D as a pair <A, D>, and rewind the tree to
> original commit A's state:
> 
>  -->A
>      \
>       D
> 
> Then you do the work that interrupted you, maybe making commits
> B and then C:
> 
>  -->A-->B-->C
>      \
>       D
> 
> At this point, you would want to restart working on whatever you
> were doing, which is the difference between A->D applied on top
> of C.
> 
> You could keep that information as a patch between A->D and
> apply it on top of C to get there, which is your approach if I
> am reading you correctly.  Carl does a three-way merge between C
> and D using A as the pivot point.
    Just out of curiosity, why isn't the SHA1 of 'A' part of the
diff or patch format?  I mean it can't be that hard to add it as a
single line of data that git can parse to extract that piece of
information.  Then a patch would enable you to do the 3-way merge
you describe.  If added properly "regular" patch would just ignore
that line.  The patch would then record that it is relative to 'A'.
    Assuming git could be taught "git-merge-patch" and then take use
the patch that's saved during the "undo" step and has the anchor for
the patch to use as the pivot point (as described above).  Life
should be good.  There are probably corner cases I don't understand,
but it sure looks like if you have the pivot or anchor point for the
patch embedded in the patch, you have all the needed information to
pull this off.
    I would think this would be generally useful outside of the
context of "undo/redo" also.
    Kirby
Previous: Junio C HamanoNext: Carl Baldwin
Message 15 of 21 in “[RFC] undo and redo”
  1. Carl BaldwinAug 24, 2005
  2. Carl BaldwinAug 24, 2005
  3. Linus TorvaldsAug 24, 2005
  4. Carl BaldwinAug 24, 2005
  5. Daniel BarkalowAug 24, 2005
  6. Carl BaldwinAug 24, 2005
  7. Daniel BarkalowAug 24, 2005
  8. Junio C HamanoAug 24, 2005
  9. Carl BaldwinAug 25, 2005
  10. Junio C HamanoAug 25, 2005
  11. Carl BaldwinAug 25, 2005
  12. Kalle ValoAug 25, 2005
  13. Kirby C. BohlingAug 25, 2005
  14. Junio C HamanoAug 25, 2005
  15. Kirby C. BohlingAug 25, 2005
  16. Carl BaldwinAug 25, 2005
  17. Carl BaldwinAug 25, 2005
  18. Kirby C. BohlingAug 25, 2005
  19. Carl BaldwinAug 25, 2005
  20. Junio C HamanoAug 24, 2005
  21. Carl BaldwinAug 24, 2005

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.