{"thread":{"id":"963","subject":"Stacked GIT 0.1 (a.k.a. quilt for git)","startedAt":"2005-06-16T22:44:32Z","lastAt":"2005-06-29T21:28:29Z","messageCount":15,"participants":["Catalin Marinas","Daniel Barkalow","Jon Seymour","Paul Jackson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"4998","messageId":"tnxy899zzu7.fsf@arm.com","threadId":"963","inReplyTo":null,"subject":"Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-06-16T22:44:32Z","receivedAt":"2005-06-16T22:44:32Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"StGIT is a Python application providing similar functionality to quilt\n(i.e. pushing/poping patches to a stack) on top of git. These\noperations are performed using the git merge algorithms. StGIT also\nallows working with the standard repository commands without having\nany patch on the stack (though not all the expected functionality is\nimplemented yet - see the TODO file in the archive).\n\nThe project page is at http://www.procode.org/stgit/\n\nBelow is a cut&paste of the README file in the archive.\n\nCatalin\n\n\n\nBasic Operations\n----------------\n\nFor a full list of commands:\n\n\tstg help\n\nFor help on individual commands:\n\n\tstg (-h | --help)\n\nTo initialise a tree:\n\n\tstg init\n\nIf there already is a .git directory, it only creates the\n.git/patches/ infrastructure. Otherwise, it creates the whole .git\ndirectory structure and imports the existing files.\n\nTo commit changes:\n\n\tstg commit\n\nTo add/delete files:\n\n\tstg add [*]\n\tstg rm [*]\n\nTo inspect the tree status:\n\n\tstg status\n\nTo get a diff between 2 revisions:\n\n\tstg diff [-r rev1[:[rev2]]]\n\nA revision name can be of the form '([patch]/[bottom | top]) | '\nIf the patch name is not specified but '/' is passed, the topmost\npatch is considered. If neither 'bottom' or 'top' follows the '/', the\nwhole patch diff is displayed (this does not include the local\nchanges).\n\nNote than when the first patch is pushed to the stack, the current\nHEAD is saved in the .git/refs/heads/base file for easy reference.\n\nTo create/delete a patch:\n\n\tstg new \n\tstg delete []\n\nThe 'new' command also sets the topmost patch to the newly created\none.\n\nTo push/pop a patch to/from the stack:\n\n\tstg push []\n\tstg pop []\n\nNote that the 'push' command can apply any patch un the unapplied\nlist. This is useful if you want to reorder the patches.\n\nTo inspect the patches applied:\n\n\tstg series\n\tstg applied\n\tstg unapplied\n\tstg top\n\nTo export a patch series:\n\n\tstg export []\n\nThe 'export' command supports options to automatically number the\npatches (-n) or add the '.diff' extension (-d).\n\nStGIT does not yet provide support for cloning or pulling changes from\na different repository. Until this becomes available, run the\nfollowing commands:\n\n\tstg pop -a\n\tyour-git-script-for-pulling-and-committing\n\tstg push -a\n\nIf you forget to pop the patches, the changes will be included in the\ntopmost patch. StGIT gives a warning on the first commit or patch\noperation and you can revert the changes. If this was the intended\nbehaviour, you either commit the changes with 'stg commit' or do a\n'stg refresh' command to synchronise the top of the patch with the\ncurrent HEAD.\n\nYou can also look in the TODO file for what's planned to be\nimpelmented in the future.\n\n\nDirectory Structure\n-------------------\n\n.git/\n objects/\n ??/\n\nrefs/\n heads/\n master\t\t- the master commit id\n base\t\t- the bottom id of the stack (to get a big diff)\n ...\n tags/\n ...\n branches/\n ...\n patches/\n applied\t\t- list of applied patches\n unapplied\t\t- list of not-yet applied patches\n current\t\t- name of the topmost patch\n patch1/\n first\t\t- the initial id of the patch (used for log)\n bottom\t\t- the bottom id of the patch\n top\t\t- the top id of the patch\n patch2/\n ...\n\nHEAD\t\t\t-> refs/heads/\n\n\nA Bit of StGIT Patch Theory\n---------------------------\n\nWe assume that a patch is a diff between two nodes - bottom and top. A\nnode is a commit SHA1 id or tree SHA1 id in the GIT terminology:\n\nP - patch\nN - node\n\nP = diff(Nt, Nb)\n\n\tNb - bottom (start) node\n\tNt - top (end) node\n\tNf - first node (for log generation)\n\nFor an ordered stack of patches:\n\nP1 = diff(N1, N0)\nP2 = diff(N2, N1)\n...\n\nPs = P1 + P2 + P3 + ... = diff(Nst, Nsb)\n\n\tPs - the big patch of the whole stack\n\tNsb - bottom stack node (= N0)\n\tNst - top stack node (= Nn)\n\nApplying (pushing) a patch on the stack (Nst can differ from Nb) is\ndone by diff3 merging. The new patch becomes:\n\nP' = diff(Nt', Nb')\nNb' = Nst\nNt' = diff3(Nst, Nb, Nt)\n\n(note that the diff3 parameters order is: branch1, ancestor, branch2)\n\nThe above operation allows easy patch re-ordering.\n\nRemoving (popping) a patch from the stack is done by simply setting\nthe Nst to Nb.\n\n"},{"id":"5005","messageId":"Pine.LNX.4.21.0506171750180.30848-100000@iabervon.org","threadId":"963","inReplyTo":"tnxy899zzu7.fsf@arm.com","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-17T22:10:24Z","receivedAt":"2005-06-17T22:10:24Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 16 Jun 2005, Catalin Marinas wrote:\n\n> StGIT is a Python application providing similar functionality to quilt\n> (i.e. pushing/poping patches to a stack) on top of git.\n\nIt might be worth making the system work for having multiple series in the\nsame tree. You could do this by saving the base commit for\n.git/refs/heads/ as .git/refs/bases/, and putting patches in\n.git/patches//. Some people do a lot with\n.git/refs/heads/something; I, at least, symlink .git/HEAD to whichever one\nI'm using, so that might be the right way to tell what the user is doing.\n\nI think it would worth exploring defining a git type for patches and\nstoring the patches inside git as well. Then a commit could identify the\npatch it applies (when it is from applying a patch), and a rebased patch\ncould reference the patch it replaces, and then (with a certain amount of\nhandwaving of implementation) the system could notice when the patch\nyou're pushing got applied upstream. Or, at least, git could avoid \nthrowing away the history information when it goes through patches. I keep\nthinking that this would be an important feature, but I haven't got the\nfamiliarity with quilt to know how it should work.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5006","messageId":"2cfc4032050617152878b75c97@mail.gmail.com","threadId":"963","inReplyTo":"Pine.LNX.4.21.0506171750180.30848-100000@iabervon.org","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-06-17T22:28:58Z","receivedAt":"2005-06-17T22:28:58Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"> \n> I think it would worth exploring defining a git type for patches and\n> storing the patches inside git as well. Then a commit could identify the\n> patch it applies (when it is from applying a patch), and a rebased patch\n> could reference the patch it replaces, and then (with a certain amount of\n> handwaving of implementation) the system could notice when the patch\n> you're pushing got applied upstream. Or, at least, git could avoid\n> throwing away the history information when it goes through patches. I keep\n> thinking that this would be an important feature, but I haven't got the\n> familiarity with quilt to know how it should work.\n> \n\nI also think it would be good if patches extracted from git\nrepositories included some information about exactly where the patch\nwas extracted from...something like...\n\n\n\nsigned-off-by: Name \n---\ncommit: sha1 -> sha1\ntree: sha1 -> sha1\n\nThe reason for including the commits is to allow the maintainer to\ntrack exactly where the a given rev of a patch was from. The reason\nfor including the treeids is to allow appliers to verify that the\npatch has produced the same result as the patch submitter.\n"},{"id":"5021","messageId":"tnxis0b1h7g.fsf@arm.com","threadId":"963","inReplyTo":"Pine.LNX.4.21.0506171750180.30848-100000@iabervon.org","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-06-18T21:35:31Z","receivedAt":"2005-06-18T21:35:31Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Daniel,\n\nThanks for your feedback.\n\nDaniel Barkalow wrote:\n> It might be worth making the system work for having multiple series in the\n> same tree. You could do this by saving the base commit for\n> .git/refs/heads/ as .git/refs/bases/, and putting patches in\n> .git/patches//. Some people do a lot with\n> .git/refs/heads/something; I, at least, symlink .git/HEAD to whichever one\n> I'm using, so that might be the right way to tell what the user is\n> doing.\n\nHaving different series would be a good idea but it might complicate\nthe tool usage. I will thing about it once I'm sure the basic\noperations work fine.\n\nBefore commenting further on your or Jon's e-mail, I want to clarify\nhow I think this tool should be used (this might be misunderstood if\nsomeone never used quilt before). First of all, a StGIT patch is a\ncollection of git commits. This tool *doesn't* remove or modify git\nchangesets.\n\nQuilt or StGIT are intended for people maintaining their own (big)\npatch on top of the Linux kernel. I will take the example of Con\nKolivas' kernel. His big patch for the -ck kernel is at\nhttp://ck.kolivas.org/patches/2.6/2.6.12-rc6/2.6.12-rc6-ck2/patch-2.6.12-rc6-ck2.diff.bz2.\nThis big patch is provided mainly for the convenience of the people\nwanting to test this kernel. If you want to get deeper into this\npatch, you can get it split in several smaller patches\n(http://ck.kolivas.org/patches/2.6/2.6.12-rc6/2.6.12-rc6-ck2/patches/).\nThis set of patches is called a 'series'. You even get a 'series' file\nwhich defines the order in which the patches should be applied.\n\nThese patches in a series represent changes to different files grouped\nafter some criteria. Let's say you have 2 schedulers, you keep them in\n2 separate patches. You can modify a scheduler and refresh\n(re-generate) its patch with quilt or simply do a 'stg commit' with\nStGIT and the change is taken into account for the topmost patch.\n\nNote that the series might remain the same for a long time but the\npatches it contains can change. When you want to upgrade the series of\npatches to a new kernel version, with quilt or StGIT you pop all the\npatches from the stack, upgrade the base (i.e. the mainline kernel)\nand push the patches back onto the stack. You can have some of the\npatches rejected in quilt or get merge conflicts with StGIT.\n\nWhile you can simply use quilt patches on top of a git repository,\nthere are advantages in using StGIT:\n\n- easier integration with a git repository with common commands like\n diff etc.\n\n- there aren't separate commands for adding/removing files to/from the\n git repository and the StGIT patch since a StGIT patch is simply\n represented as two commit ids - the base (bottom) and the top of the\n patch (those familiar with quilt know what it means to modify a file\n without adding it first to the topmost patch)\n\n- every time you commit some changes (with 'stg commit'), this\n changeset is added to the topmost patch on the stack (by replacing\n the top id of the patch with the new commit id). If you want to\n modify a patch, simply push/pop until it becomes the topmost one,\n make the changes and commit. All the commit history is preserved\n (unlike quilt where you update the patch with a 'refresh'\n command). With a future StGIT release you will be able to see the\n log for individual StGIT patches\n\n- pushing a patch to the stack when the base changed is done by\n merging with a diff3 algorithm. I find this slightly superior to a\n simple 'patch -p1 < file.diff' (well, some people do not agree with\n this point)\n\n> I think it would worth exploring defining a git type for patches and\n> storing the patches inside git as well. Then a commit could identify the\n> patch it applies (when it is from applying a patch), and a rebased patch\n> could reference the patch it replaces, and then (with a certain amount of\n> handwaving of implementation) the system could notice when the patch\n> you're pushing got applied upstream. Or, at least, git could avoid \n> throwing away the history information when it goes through patches. I keep\n> thinking that this would be an important feature, but I haven't got the\n> familiarity with quilt to know how it should work.\n\nI don't know whether this is still valid after clarifying the intended\nuse of StGIT. When a patch was merged upstream, the local push\noperation should detect that the patch being pushed doesn't change\nanything and, at this point, you can safely delete it.\n\n-- \nCatalin\n\n"},{"id":"5022","messageId":"tnxekaz1guv.fsf@arm.com","threadId":"963","inReplyTo":"2cfc4032050617152878b75c97@mail.gmail.com","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-06-18T21:43:04Z","receivedAt":"2005-06-18T21:43:04Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Jon Seymour wrote:\n> I also think it would be good if patches extracted from git\n> repositories included some information about exactly where the patch\n> was extracted from...something like...\n>\n> signed-off-by: Name \n> ---\n> commit: sha1 -> sha1\n> tree: sha1 -> sha1\n>\n> The reason for including the commits is to allow the maintainer to\n> track exactly where the a given rev of a patch was from. The reason\n> for including the treeids is to allow appliers to verify that the\n> patch has produced the same result as the patch submitter.\n\nSee my (long) reply to Daniel. A StGIT patch is a collection of git\ncommits, mixed in time with commits for other patches. There might not\nbe a single author. For example, I create a patch called\n'stabilisation' where I gather different git changesets from different\nauthors and commit them one by one.\n\nI think what you mean is similar to the cg-mkpatch command. The 'stg\nexport' is totally different. While it might be possible to generate a\nset of changesets for a StGIT patch, this is not intended for the near\nfuture.\n\n-- \nCatalin\n\n"},{"id":"5030","messageId":"Pine.LNX.4.21.0506182338300.30848-100000@iabervon.org","threadId":"963","inReplyTo":"tnxis0b1h7g.fsf@arm.com","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-19T04:26:25Z","receivedAt":"2005-06-19T04:26:25Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 18 Jun 2005, Catalin Marinas wrote:\n\n> Having different series would be a good idea but it might complicate\n> the tool usage. I will thing about it once I'm sure the basic\n> operations work fine.\n\nYou could future-proof yourself a bit by simply saving the base as\n.git/refs/bases/master and making the patches be\n.git/patches/master/. That way, you'd be ready when you start to support\nmultiple series.\n\n> Before commenting further on your or Jon's e-mail, I want to clarify\n> how I think this tool should be used (this might be misunderstood if\n> someone never used quilt before). First of all, a StGIT patch is a\n> collection of git commits. This tool *doesn't* remove or modify git\n> changesets.\n\n(snip)\n\nOkay; this fits what I thought quilt and StGIT did. \n\nAn aside:\n\n> - pushing a patch to the stack when the base changed is done by\n> merging with a diff3 algorithm. I find this slightly superior to a\n> simple 'patch -p1 < file.diff' (well, some people do not agree with\n> this point)\n\ndiff3 is clearly superior to patch in how effective it is; the\ndisagreement is only over how useful the output format is. But diff3 gets\nall the information that patch gets, plus more, so it would have to be\nbuggy if it did worse, aside from by patch getting lucky. (Also, patch can\nbe used in situations where diff3 couldn't, due to having no known common\nancestor). IIRC, diff3 can generate .rej files if you tell it to, rather\nthan reporting conflicts inline.\n\n> I don't know whether this is still valid after clarifying the intended\n> use of StGIT. When a patch was merged upstream, the local push\n> operation should detect that the patch being pushed doesn't change\n> anything and, at this point, you can safely delete it.\n\nIf you're lucky, it will generate only a warning that changes are present\nin both trees, the push will have no effect, and StGIT can determine that\nthe rebased patch is now empty. But consider this situation:\n\nYou have three patches stacked on a base.\n\nThe mainline takes a patch from somewhere else, then the first of your\npatches, then a second patch from somewhere else. The last of these is\nbased on your first patch (or on mainline after your patch went in).\n\nThen you update.\n\nWhen you try to push your first patch, merge sees the common base, your\nchange, and the current mainline. There is no way to tell, from the\ninformation available, that the correct merge is to ignore your change in\nfavor of mainline's version; the program only sees that there were two\ndifferent changes to the same area. The information which would resolve\nthis were patches not used would be that there was a mainline commit that\nmerged your first patch; the left side of the merge is an ancestor of the\nright side, so the merge is the right side. My goal is to get the same\ninformation into the system so it can reach the same conclusion when\npatches are used.\n\nNote that it gets more complex if mainline takes only your second patch\n(due to it not requiring your first, and your first not being as\nacceptable). In this case, it needs to entire mainline as a patch, because\nmerges can't cherrypick, whereas patches can act arbitrarily. But it would\nbe nice to store the information of what happened even with patches that\ncherrypick, such that we have a better chance for managing things later.\n\nThe above situation is not actually particular to StGIT or quilt; any case\nwhere something gets exported as a patch and applied to a different base\nhas this problem. But I think that you have the right ideas about how\npatches should be represented, and it would be good to get your\nrepresentation implemented inside git, because operations more central to\ngit would benefit from having this information.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5035","messageId":"tnxll56y9zy.fsf@arm.com","threadId":"963","inReplyTo":"Pine.LNX.4.21.0506182338300.30848-100000@iabervon.org","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-06-19T09:24:49Z","receivedAt":"2005-06-19T09:24:49Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Daniel Barkalow wrote:\n> On Sat, 18 Jun 2005, Catalin Marinas wrote:\n>> Having different series would be a good idea but it might complicate\n>> the tool usage. I will thing about it once I'm sure the basic\n>> operations work fine.\n>\n> You could future-proof yourself a bit by simply saving the base as\n> .git/refs/bases/master and making the patches be\n> .git/patches/master/. That way, you'd be ready when you start to support\n> multiple series.\n\nYou are right. I will do this for the next release (0.2, probably of\nthe end of this week), something like the tree structure below:\n\n.git/refs/bases/\n.git/series//\n.git/series//applied\n.git/series//unapplied\n.git/series//current\n.git/series//patches/*\n\nI don't know whether a git-diff-* command would look into\n.git/refs/bases (I can do this in stgit but, this was only for\nconvenience).\n\n[...]\n> Note that it gets more complex if mainline takes only your second patch\n> (due to it not requiring your first, and your first not being as\n> acceptable). In this case, it needs to entire mainline as a patch, because\n> merges can't cherrypick, whereas patches can act arbitrarily. But it would\n> be nice to store the information of what happened even with patches that\n> cherrypick, such that we have a better chance for managing things\n> later.\n\nYou can cherry-pick the second patch by first commuting it with the\nprevious patches. If they are independent, the commuting via diff3\nwouldn't generate any conflict. Even with the current stgit, you can\npop all the patches and only push those to be merged upstream. HEAD\nwould only contain the those patches.\n\nIf you want to implement a full-featured patch treacking, you might\nend up with something like darcs which doesn't scale to the size of\nthe Linux kernel. On the other hand, you might not agree with the\nchanges to your accepted patch and a conflict is welcomed so that you\ncan choose whether to keep the old version or not.\n\n> But I think that you have the right ideas about how\n> patches should be represented, and it would be good to get your\n> representation implemented inside git, because operations more central to\n> git would benefit from having this information.\n\nDo you mean creating a new git type like the blob, tree or commit? I\nwould prefer not to modify git or have my own version of git. StGIT\nshould be a tool running directly on top of an existing installation\nof git.\n\nInstead of having a directory for every patch (with bottom, top\netc. files), I could create a git blob to store this information and\nthe series files (applied/unapplied files) would only contain the blob\nid. This could simplify things if, in a future version, stgit would\nallow patch cherry-picking.\n\n-- \nCatalin\n\n"},{"id":"5205","messageId":"20050623175848.1cf41a52.pj@sgi.com","threadId":"963","inReplyTo":"tnxy899zzu7.fsf@arm.com","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-06-24T00:58:48Z","receivedAt":"2005-06-24T00:58:48Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"Interesting idea. Thanks.\n\nI am just firing it up now - noticing a couple of nits:\n\n 1) \"Unknown\" is misspelled as \"Unkown\" in a couple places.\n\n 2) I tried doing an \"stg init\" in the stgit subtree that I had\n just unpacked and installed (python setup.py install). This\n did several lines of \"Adding ...\" and then displayed the\n number \"16\" and sat there. I typed some random guesses at\n it, and realized I was inside my $EDITOR=/bin/ed.\n\n Before invoking an editor, it would be a good idea to tell the\n user you are doing so. If someone is on a telnet session to\n a system with their $DISPLAY set wrong, they might not even\n get the terse \"16\" clue that I got, that they are editing\n something.\n\n 3) My editor 'ed' exits with non-zero status if I make even the most\n trivial editing error. This resulted in this \"stg init\" failing\n with:\n\tstg init: Editor (ed .commitmsg) failed\n I'd recommend ignoring the exit status of externally invoked\n editors.\n\n 4) I tried rerunning that \"stg init\" without further ado, and it\n failed again (due to the incomplete init above, no doubt), with:\n\n\tTraceback (most recent call last):\n\t File \"/usr/bin/stg\", line 25, in ?\n\t main()\n\t File \"/usr/lib/python2.4/site-packages/stgit/main.py\", line 557, in main\n\t command.func(parser, options, args)\n\t File \"/usr/lib/python2.4/site-packages/stgit/main.py\", line 91, in init\n\t stack.init()\n\t File \"/usr/lib/python2.4/site-packages/stgit/stack.py\", line 187, in init\n\t patch_dir = get_patch_dir()\n\t File \"/usr/lib/python2.4/site-packages/stgit/stack.py\", line 36, in get_patch_dir\n\t return os.path.join(git.base_dir, 'patches', git.get_head_file())\n\t File \"/usr/lib/python2.4/posixpath.py\", line 60, in join\n\t if b.startswith('/'):\n\tAttributeError: 'NoneType' object has no attribute 'startswith'\n\n 5) I tried again, doing:\n\n\trm -fr .git\n\tstg init\n\t# on the commit message edit - just quit 'q', to avoid any error exit\n\n This failed again, leaving my new git tree in god only knows what bogus state.\n It failed with:\n\n\tstg init: Commit message not modified\n\n I'm getting a little frustrated by now. Guess I will just nuke the .git subtree\n and try again, as I have no clue what useful or bogus state this left me in.\n\n Try generating fewer fatal errors, and try giving a tiny clue what state (ok or\n not or how bad) one is left in after an apparently fatal error, and for extra\n credit, a clue what to do next.\n\n 6) Ok - got through the init that time.\n\nSince I am fond of both quilt and Python, and since I need to be using git and/or cogito,\nI will poke around some more with this - it's promising.\n\nI see something about a patch emailer on the todo list -- you're welcome to make use of\nmy patch emailer (I use with quilt, though it's not tightly bound to quilt) at:\n\n http://www.speakeasy.org/~pj99/sgi/sendpatchset\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.925.600.0401\n"},{"id":"5208","messageId":"tnxd5qc6s5o.fsf@arm.com","threadId":"963","inReplyTo":"20050623175848.1cf41a52.pj@sgi.com","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-06-24T09:05:55Z","receivedAt":"2005-06-24T09:05:55Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Hi Paul,\n\nThanks for trying it. As a note, for the moment you should try the\nlatest daily snapshot since it contains less bugs than the main\n(alpha) releases.\n\nPaul Jackson wrote:\n> 1) \"Unknown\" is misspelled as \"Unkown\" in a couple places.\n\nThanks.\n\n> Before invoking an editor, it would be a good idea to tell the\n> user you are doing so. If someone is on a telnet session to\n> a system with their $DISPLAY set wrong, they might not even\n> get the terse \"16\" clue that I got, that they are editing\n> something.\n\nDone.\n\n> I'd recommend ignoring the exit status of externally invoked\n> editors.\n\nOK, fixed.\n\n> 4) I tried rerunning that \"stg init\" without further ado, and it\n> failed again (due to the incomplete init above, no doubt), with:\n>\n[...]\n> \tAttributeError: 'NoneType' object has no attribute\n> \t'startswith'\n\nThe problem here is that the .git/HEAD link is not valid if init\nfailed. I will fix it for the tonight's snapshot.\n\n> 5) I tried again, doing:\n>\n> \trm -fr .git\n> \tstg init\n> \t# on the commit message edit - just quit 'q', to avoid any error exit\n>\n> This failed again, leaving my new git tree in god only knows what bogus state.\n> It failed with:\n>\n> \tstg init: Commit message not modified\n\nI can remove this condition for init only. The problem is that if it\nno longer exists on an non-zero editor exit status, it should at least\ncheck whether the commit message was modified.\n\n> Try generating fewer fatal errors, and try giving a tiny clue\n> what state (ok or not or how bad) one is left in after an\n> apparently fatal error, and for extra credit, a clue what to do\n> next.\n\nI will try to add as much as information as possible. I initially\nwanted to get something working and be able to push/pop patches. I\nhaven't tried the init command with different editors etc.\n\n> 6) Ok - got through the init that time.\n\nGood.\n\n> Since I am fond of both quilt and Python, and since I need to be\n> using git and/or cogito,\n> I will poke around some more with this - it's promising.\n\nGreat. Pushing/popping works fine at the moment with my kernel tree\n(but with less than 10 patches on the stack). It even detected when\nthe patches I submitted were merged upstream.\n\nThe next thing on my plan a log command. I would like to be able to\npreserve the history of a patch but this probably won't be available\nin an upstream tree pulling from yours.\n\n> I see something about a patch emailer on the todo list -- you're\n> welcome to make use of my patch emailer (I use with quilt, though\n> it's not tightly bound to quilt) at:\n>\n> http://www.speakeasy.org/~pj99/sgi/sendpatchset\n\nThanks. I will try to include this in a future version.\n\n-- \nCatalin\n\n"},{"id":"5210","messageId":"20050624034743.6c3bdae4.pj@sgi.com","threadId":"963","inReplyTo":"tnxd5qc6s5o.fsf@arm.com","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-06-24T10:47:43Z","receivedAt":"2005-06-24T10:47:43Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"> it should at least\n> check whether the commit message was modified.\n\nI suspect not.\n\nBeware that quilt has tended toward the philosophy of doing just\nwhat you said, with no more, perhaps less than, the minimum critical\nconsistency checking. If you tried to shoot you foot off with it,\nit shot your foot off, quickly.\n\nIf I try to make a change without a meaninguful log entry, what\nbusiness of stgit is that? And it certainly should not leave the\ntree in some unspecified, inconsistent state without prior warning\non account of such.\n\nDon't add inessential sanity checks on user input. It won't sell\nwell to the \"quilt replacement\" market.\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.925.600.0401\n"},{"id":"5211","messageId":"tnxhdfo56yd.fsf@arm.com","threadId":"963","inReplyTo":"20050624034743.6c3bdae4.pj@sgi.com","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-06-24T11:29:14Z","receivedAt":"2005-06-24T11:29:14Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Paul Jackson wrote:\n>> it should at least\n>> check whether the commit message was modified.\n>\n> I suspect not.\n>\n> Beware that quilt has tended toward the philosophy of doing just\n> what you said, with no more, perhaps less than, the minimum critical\n> consistency checking. If you tried to shoot you foot off with it,\n> it shot your foot off, quickly.\n>\n> If I try to make a change without a meaninguful log entry, what\n> business of stgit is that?\n\nThe way to modify a patch with stgit is via 'stg commit'. The problem\nis that you can end up with a commit log you didn't want simply\nbecause the editor crashed or $EDITOR is invalid and there is no way\nto modify the log history.\n\nWith stgit you don't have files only specific to a patch (the 'quilt\nadd' command equivalent is missing). When you modify a file and commit\nthe changes, it will be included in the topmost patch. IMO, this\nsimplifies the command set and avoids having two different add\ncommands (or a single add command with different behaviours). Now,\nsome people might not run a 'stg status' before a commit but they find\nout from the commit msg that an unrelated file was modified. You could\nsimply exit without saving the commit msg and the changes won't be\nchecked in (and the tree is left in a consistent state - the one\nbefore the commit).\n\nAnyway, if you don't care about the commit history for individual\npatches, I can simply remove all this commit/editor/msg check and just\nuse a standard text, maybe a description of the patch so that people\npulling from your git tree would know what it is about.\n\n> And it certainly should not leave the\n> tree in some unspecified, inconsistent state without prior warning\n> on account of such.\n\n'commit' failing doesn't leave the tree in an unspecified state (at\nleast not the yesterday's snapshot). There are other commands that do\nthis, unfortunately, but I'm still working on this.\n\n> Don't add inessential sanity checks on user input. It won't sell\n> well to the \"quilt replacement\" market.\n\nI'm not keen on keeping these sanity checks but see my reasons above\nfor the commit message. Anyway, I'm open to suggestions. The main\nadvantage of stgit over quilt is that it uses diff3 instead of patch\nfor pushing patches. For this to work properly, the top and bottom of\na patch have to be valid commit or tree objects containing the whole\ntree even if most of the files are not modified by this patch.\n\n-- \nCatalin\n\n"},{"id":"5213","messageId":"20050624045627.6e9cbaff.pj@sgi.com","threadId":"963","inReplyTo":"tnxhdfo56yd.fsf@arm.com","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-06-24T11:56:27Z","receivedAt":"2005-06-24T11:56:27Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"> there is no way to modify the log history.\n\nAha. If that means what I think it does, then I suspect I will remain\nwith quilt. The per-patch comment is often about the last thing that\nI put in the patch.\n\nThe special thing about quilt is that the patch set in every regard\nis infinitely changeable - the selection and order of the patches,\nthe contents of the patches, and the comments and metadata associated\nwith the patch can all be edited trivially.\n\nQuilt is not a change management system; it's a patch set composition\nsystem.\n\nThat stgit is layered on git (a persistent data store), and that\nit has something (the log history you mention above) that cannot\nbe modified, suggests that stgit is not a 'better quilt for git',\nbut some other sort of tool.\n\nGood luck ;).\n\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.925.600.0401\n"},{"id":"5216","messageId":"tnx4qbo548i.fsf@arm.com","threadId":"963","inReplyTo":"20050624045627.6e9cbaff.pj@sgi.com","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-06-24T12:27:57Z","receivedAt":"2005-06-24T12:27:57Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Paul Jackson wrote:\n>> there is no way to modify the log history.\n>\n> Aha. If that means what I think it does, then I suspect I will remain\n> with quilt. The per-patch comment is often about the last thing that\n> I put in the patch.\n\nI think you got it a bit wrong.\n\nThat was the initial idea. Anyway, in a future version you will have\none commit which is trackable via HEAD and which represents the whole\npatch. This commit's log should always contain the patch description\nso that people pulling your HEAD know what it is about.\n\nIf this is useful, a patch can have a second commit (or chain of\ncommits) refering to the same tree but not trackable via .git/HEAD but\nwhich can be useful to track the individual changes of a patch. This\nwould be stored under .git/patches/// and not accessible\nto anyone pulling the HEAD (well, rsync might bring the object but it\ncan be cleaned-up). This might be useful if you have a bigger patch\nand want to track its changes, only internally.\n\nAnyway, I think I won't implement this second commit handling and the\nper-patch history would be trashed. Now I think I understand why you\nmean by not caring about the commit message.\n\n> The special thing about quilt is that the patch set in every regard\n> is infinitely changeable - the selection and order of the patches,\n> the contents of the patches, and the comments and metadata associated\n> with the patch can all be edited trivially.\n\nAlmost all of this can be done with stgit. A patch in stgit is a just\na diff between 2 snapshots of the tree. The patch is indefinitely\nchangeable via commit. This weekend I will implement the proper commit\nhandling so that every new commit represents the whole patch and not\njust the last modification.\n\nYou can easily reorder patches by popping all of them and pushing in a\ndifferent order. This is done via diff3 merging.\n\n> Quilt is not a change management system; it's a patch set composition\n> system.\n\nI think the confusion comes from the fact that I wanted to put both\npatch composition and change management in the same tool without a\nclear separation.\n\n> That stgit is layered on git (a persistent data store), and that\n> it has something (the log history you mention above) that cannot\n> be modified, suggests that stgit is not a 'better quilt for git',\n> but some other sort of tool.\n\nAgain, the log history should only be internal, if useful, and not\nvisible to the outside world.\n\n> Good luck ;).\n\nThanks. At least it is good that you tried it and provided some ideas\nabout what's needed as a quilt replacement. I will release a 0.3\nversion this weekend with the above things and you can try it.\n\n-- \nCatalin\n\n"},{"id":"5333","messageId":"tnxwtoeiysf.fsf@arm.com","threadId":"963","inReplyTo":"20050624045627.6e9cbaff.pj@sgi.com","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-06-28T10:03:12Z","receivedAt":"2005-06-28T10:03:12Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Paul Jackson wrote:\n>> there is no way to modify the log history.\n>\n> Aha. If that means what I think it does, then I suspect I will remain\n> with quilt. The per-patch comment is often about the last thing that\n> I put in the patch.\n\nOK, you convinced me :-). I will upload a new StGIT version tonight. I\nremoved the 'commit' command completely. To add changes into the\nrepository, you would use the 'refresh' command. There is only one git\ncommit object for each patch and they can be seen with tools like\ncg-log on top of the stack base (i.e. the HEAD of the pulled tree).\n\nThere is no per-patch history anymore. The patch diff and information\n(description, author name etc.) are indefinitely changeable via the\n'refresh' command but only one commit with the latest information is\nseen in the tree log for each patch.\n\nTo pull new changes from the master repository:\n\n stg pop -a\n cg-udpate (or whatever people use to pull and merge)\n stg push -a\n\nThe 'push' command re-bases all the commits corresponding to the StGIT\npatches.\n\nDoes this make it closer to quilt in functionality?\n\n-- \nCatalin\n"},{"id":"5423","messageId":"20050629142829.32208ad8.pj@sgi.com","threadId":"963","inReplyTo":"tnxwtoeiysf.fsf@arm.com","subject":"Re: Stacked GIT 0.1 (a.k.a. quilt for git)","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-06-29T21:28:29Z","receivedAt":"2005-06-29T21:28:29Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"Catalin wrote:\n> Does this make it closer to quilt in functionality?\n\nIt could - right now I'm playing with Matt Mackall's Mercurial. Sorry.\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.925.600.0401\n"}]}