{"thread":{"id":"6239","subject":"[RFC] Adding stack-level logging/undo to StGIT","startedAt":"2007-01-05T23:19:44Z","lastAt":"2007-01-11T00:06:55Z","messageCount":2,"participants":["Yann Dirson","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30928","messageId":"20070105231944.GB6179@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6239","inReplyTo":null,"subject":"[RFC] Adding stack-level logging/undo to StGIT","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-05T23:19:44Z","receivedAt":"2007-01-05T23:19:44Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"This mail is a draft collection of design ideas to hopefully progress\ntowards full \"undo\" functionnality in StGIT.  The issue is not\ntrivial, so I'd prefer to hear from users before starting to code\nanything :)\n\n\nThe main goal with this feature is to provide a log of what happenned\nto a stgit stack, with sufficient details to be able to undo any\nnumber of operations.  A \"stg undo\" (and fellow \"stg redo\") would\nreplace current --undo flags that only a couple of commands implement.\nAnother command (maybe \"stg slog\" ?) would allow to examine this log.\n\nSince some existing stgit operations are already made of several more\nelementary operations, the log will most likely have to record sort of\nBEGIN/END events, which will pave the way to transactions.\n\n\nWhat I'm thinking of is to use a mechanism similar to the one already\nused for patch logs: the stack log would use its own head ref pointing\nto a commit describing the operation, with the stacklog commit for the\nprevious operation as parent.\n\nInformation to be available from a stacklog commit include:\n\n- the series file\n- the current top patchname\n- the relevant patchlog commits\n\nThe current top can be put into a \"Current:\" pseudo-header in the\ncommit message.\n\nThe series file seems a good candidate to be history-tracked by GIT\n(in its own tree if necessary - a tree would even provide some place\nto extend the mechanism when needed).\n\nThe list of patchlog commits, ordered by the series file, may or may\nnot be useful to history-track.  It could be kept in a blob alongside\nthe series file, or could be part of the stacklog commit message.  The\nlatter would allow to jump from stacklog to patchlog in gitk at no\ncost (although that's hardly an excuse per se ;).\n\n\nWhich patchlogs should be referenced by a stacklog entry ?\n\nI would rule out those for patches left unapplied by the operation,\nwhich (unless I miss some point) are by definition not touched by that\noperation (I'm talking about elementary operations like\npush/pop/new/delete here - compound operations can obviously have\nside-effects, recorded in the elementary stacklogs that build them up).\n\nFor elementary operations as well, it looks like just recording the\npatchlog for the patch left at the top by the operation could be\nenough.  Or do I miss something ?\n\n\nMaybe maintainance of the stacklog requires a separate index file ?\n\n\nFor compound operations, I'd like to be able to handle them as a\nsingle operation for most purpose - ie, \"stg undo\" after a \"stg push\np1\" would both undo the push like \"stg push --undo\" currently does,\nand as well revert the series order to put p1 back where it was\nlocated.\n\nThat is, a compound operation would be represented in the stack log by\na single commit.  That commit would in turn point to the sequence of\nelementary commits that make the compound, probably by a \"Sublogs:\"\npseudo-header in the compound stacklog message.\n\nUntil a compound operation has been finalized, we would store in the\nstacklog the operations that will make the compound, using a special\n\"BEGIN\" operation to mark the start of the transaction.  When\nfinalizing the transaction, those would be moved from the main\nstacklog to the compound stacklog entry, which would replace them.\n\nProblem: with this design, the first operation in the compound will\npoint to the BEGIN op as its parent; I would prefer to have it point\nto the compound's parent (ie. the previous real operation on the\nstack).  That would allow to easily \"break a transaction\", either\nbefore it's finished, or afterwards by \"undoing into it\".\n\nSo probably we should keep the BEGIN marker somewhere else.\nAny strong ideas out there ?\n\nBest regards,\n-- \nYann.\n"},{"id":"31423","messageId":"b0943d9e0701101606w649fc26ara73f2c9212de4a33@mail.gmail.com","threadId":"6239","inReplyTo":"20070105231944.GB6179@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [RFC] Adding stack-level logging/undo to StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-01-11T00:06:55Z","receivedAt":"2007-01-11T00:06:55Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 05/01/07, Yann Dirson <ydirson@altern.org> wrote:\n> This mail is a draft collection of design ideas to hopefully progress\n> towards full \"undo\" functionnality in StGIT.  The issue is not\n> trivial, so I'd prefer to hear from users before starting to code\n> anything :)\n\n(couldn't finish reading all the e-mail, too long :-) and I'm too tired)\n\nThe idea of transactions and unified undo/redo is very good but it's a\nbit more complicated with the current structure, which I admit isn't a\ngood design (too many files and metadata; I initially started StGIT as\nshell script prototype and moved to Python without re-designing the\nstructure). Ideally, we would have the full stack state in a single\nfile that could be stored as git object and get unlimited undo\nfacilities or history tracking.\n\nBut this is part of a post 1.0 development. I plan to fix some of the\noutstanding issues (still need to create the TODO wiki page) and go\ntowards a first 1.0 release candidate (and release 1.0 sometime this\nspring). I think StGIT now has most of the features I initially\nplanned for 1.0. After that we can re-design the current structure and\nmake it simpler to support transactions and full history for both\npatches and the stack as a whole.\n\n-- \nCatalin\n"}]}