{"thread":{"id":"6057","subject":"Re: Collection of stgit issues and wishes","startedAt":"2006-12-08T22:17:44Z","lastAt":"2006-12-21T23:48:46Z","messageCount":22,"participants":["Jakub Narebski","Catalin Marinas","David Kågedal","Yann Dirson","Karl Hasselström","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298629","messageId":"20061208221744.GA3288@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6057","inReplyTo":null,"subject":"Collection of stgit issues and wishes","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-12-08T22:17:44Z","receivedAt":"2006-12-08T22:17:44Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"Here is the remaining of my queue of stgit issues and ideas noted\nin the last months. A number of items in the \"wishlist\" section is\nreally here to spawn discussion. Maybe some of them should end up\nin the TODO list.\n\nbugs:\n\n- \"show\" still shows previous patch, after pushing resulted in empty patch\n(after solving conflict, when \"refresh\" then has nothing to do)\n- \"stg import\" leaves empty patch on the stack after failed patch application\n- \"push --undo\" should restore series order\n- \"import --strip\" is too eager (eg. eats numeric prefix when we only\nwant to strip a .diff suffix). Probably better symetry with export\nflags would be useful.\n- \"push\" fails with \"Unknown patch name:\" when asked to push a patch\nalready applied\n- \"stg fold\" usage does not tell what is used for\n- \"patches -d\" may be confused by files added then removed (below,\nfile added to platform-v0, removed in rm-junk, problem encountered on\n2006-08-14, probably on 0.10):\n|$ stg patches include/linux/mtd/nand.h.old\n|platform-v0\n|ieee-lct-bouton\n|rm-junk\n|$ stg patches include/linux/mtd/nand.h.old -d\n|-------------------------------------------------------------------------------\n|platform-v0\n|-------------------------------------------------------------------------------\n|Kernel for V0 platform\n|---\n|\n|stg patches: ['git-diff-tree', '-p',\n|'7a9c28b56f5f210e11632388ffb554ae2cb04492',\n|'a8e874d6090bc6274cadcff64faf7cff151b9b5c', 'include/linux/mtd/nand.h.old']\n|failed (fatal: ambiguous argument 'include/linux/mtd/nand.h.old': unknown\n|revision or path not in the working tree.\n|Use '--' to separate paths from revisions)\n\nusability problems:\n\n- \"refresh\" should display .git/conflicts if any ?\n- patches/*/*.log branches could be better named as patchlogs/*/*\n(easier to filter reliably)\n- \"stg show\" should catch inexistant patch instead of saying \"Unknown\nrevision: that-patch^{commit}\"\n- \"clean\" should give enough info for the user to locate any problem\n(eg. conflict with files removed from revision control), eg. with a\n\"popping to ...\" message\n- \"stg fold\" should allow to pass -C to git-apply: context mismatch\ncurrently makes folding unnecessarily hard\n|$ stg show d-lessdebug | filterdiff -#3 | stg fold\n|Folding patch from stdin...stg fold: Patch does not apply cleanly\n|$ stg show d-lessdebug | filterdiff -#3 | patch -p1\n|patching file drivers/ieee1394/gp2lynx.c\n|Hunk #1 succeeded at 2074 with fuzz 2 (offset -96 lines).\n- \"stg pick patch@branch\" needs non-intuitive \"stg push --undo\" to cancel :\nadd \"stg pick --undo ?\"\n- \"stg pick --fold\" needs even less-intuitive \"stg push --undo && stg\npush\" or \"stg status --reset\"\n\n\nwishlist and wild ideas:\n\n- lacks syntax for \"(n) patches before/after X\"\n- \"stg goto \" causes IndexError exception\n- needs series logging in addition to patch logging\n- \"stg pull --undo\" to move the stack base back to previous place\n(esp. useful after \"push\" detected a conflict we don't want to handle\nright now)\n- single-arg \"stg rename\" to rename current patch ?\n- lacks undo for \"pick --fold\"\n- \"sink\" or \"burry\" as opposite to \"float\" (possibly with a target\npatch)\n- lacks \"pick --patch=XXX\" to pick by name\n- \"stg clean\" could take a list of patches, to allow being used in scripts\n- \"stg fold\" lacks --reverse\n- interactive merge tools could only be called automatically after\nfailed merge, instead of requiring not-so-intuitive \"resolved -i\"\n- needs a config example to call ediff via gnuserv (possibly sending\nseveral merges at a time, making use of the session registry)\n- shortcuts (st -> status, etc.), possibly making use of the git alias\nsystem ?\n- \"stg fold\" should allow to run a merge (insert conflict markers, or\neven just output a .rej patch somewhere)\n- support for atomicity of complex transactions (stg begin/snapshot,\nrollback, commit/finish - possibly with a transaction name so nesting would\njust work)\n- support for pure patch reordering when a move causes conflicts.\nMaybe a way to start a transaction while declaring the patch range\nwhich has to be reordered, ensuring that finalising the transaction\nwould end with the desired tree state unchanged.\n- mark patches as deactivated (float above all unapplied ones), so\neven \"push -a\" would not push them\n- \"stg diff\" should allow to use diff flags like -w or -b (GIT_DIFF_OPTS\ndoes not work)\n"},{"id":"298055","messageId":"elconr$uku$2@sea.gmane.org","threadId":"6057","inReplyTo":"20061208221744.GA3288@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Collection of stgit issues and wishes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-08T22:27:18Z","receivedAt":"2006-12-08T22:27:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Here are some issues which are a bit annoying for me:\n- make \"stg help\" (without command name) equivalent to \"stg --help\"\n- stg new lacks --sign option (I have to remember to do this during\n \"stg refresh\").\n\nStacked GIT 0.11\ngit version 1.4.4.1\nPython version 2.4.3 (#1, Jun 13 2006, 16:41:18) \n[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)]\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297666","messageId":"elght6$tjb$1@sea.gmane.org","threadId":"6057","inReplyTo":"elconr$uku$2@sea.gmane.org","subject":"Re: Collection of stgit issues and wishes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-10T08:55:13Z","receivedAt":"2006-12-10T08:55:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> Here are some issues which are a bit annoying for me:\n> - make \"stg help\" (without command name) equivalent to \"stg --help\"\n> - stg new lacks --sign option (I have to remember to do this during\n> \"stg refresh\").\n\nAnd another one: git uses VISUAL, then EDITOR, while stgit uses EDITOR\nonly, so when I prepare VISUAL for git (I use emacsclient), stgit still\nuses EDITOR.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295532","messageId":"elgpjk$ggm$1@sea.gmane.org","threadId":"6057","inReplyTo":"elght6$tjb$1@sea.gmane.org","subject":"Re: Collection of stgit issues and wishes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-10T11:06:40Z","receivedAt":"2006-12-10T11:06:40Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n>> Here are some issues which are a bit annoying for me:\n>> - make \"stg help\" (without command name) equivalent to \"stg --help\"\n>> - stg new lacks --sign option (I have to remember to do this during\n>> \"stg refresh\").\n\nAnd as far as I can see it doe not use git credentials (user.name and\nuser.email).\n\n> And another one: git uses VISUAL, then EDITOR, while stgit uses EDITOR\n> only, so when I prepare VISUAL for git (I use emacsclient), stgit still\n> uses EDITOR.\n\nAnd yet another one: better support for reflog, namely giving the \"reason\"\ni.e. the reflog message (like \"stg push: \", \"stg refresh:\n\", \"stg pop: \", \"stg commit\" etc.), like git-rebase,\ngit-commit --amend and git-am (for example) does.\n\n\nP.S. The Vendor: field in stgit RPM has incorrectly\n Catalin Marinas \ninstead of\n Catalin Marinas \n(.org instead of .com).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297803","messageId":"b0943d9e0612100825h3ef2fa77kd5d9fd5022cbb3f9@mail.gmail.com","threadId":"6057","inReplyTo":"20061208221744.GA3288@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Collection of stgit issues and wishes","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-12-10T16:25:52Z","receivedAt":"2006-12-10T16:25:52Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 08/12/06, Yann Dirson wrote:\n> Here is the remaining of my queue of stgit issues and ideas noted\n> in the last months. A number of items in the \"wishlist\" section is\n> really here to spawn discussion. Maybe some of them should end up\n> in the TODO list.\n\nSince this list gets changed pretty often, I would rather add TODO\nBugs wiki pages on http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT\n(maybe I should create a page on one of the open-source hosting sites\nand get some bug-tracking support). I keep the TODO file mainly for\nwhat I plan to implement and, while I agree with many of the issues\nyou point below, I don't guarantee I have time to fix/implement.\n\nFrom your list below, I removed those which I don't have any comments\nfor (I agree with you).\n\n> - \"stg import\" leaves empty patch on the stack after failed patch application\n\nThat's a feature in the sense that it creates the empty patch with the\ndescription and author information. It also leaves a\n.stgit-failed.patch which you can manually apply.\n\n> - \"push --undo\" should restore series order\n\nYes, but it requires some work to store the old series information\n\n> - \"stg fold\" usage does not tell what is used for\n\nI think \"stg help fold\" is somewhat clear in this respect but, well,\nit could be improved.\n\n> - \"patches -d\" may be confused by files added then removed (below,\n> file added to platform-v0, removed in rm-junk, problem encountered on\n> 2006-08-14, probably on 0.10):\n\nIs this still the case now? I fixed a similar issue a few months ago\n(commit a57bd72016d3cf3ee8e8fd7ae2c12e047999b602; GIT considers a file\nname to be revision name if the file isn't found on disk; easily\nfixable by adding the \"--\" separator).\n\nOnly the push and pick comands take renames into account at the moment\n(by using git-merge-recursive). It's not hard to modify the other\ncommands to deal better with renames, only that I didn't have time to\ndo it. There might be some performance impact on some commands. There\nis also the case that I want to be able to send patches in a standard\nGNU diff format for people not using GIT.\n\n> - \"refresh\" should display .git/conflicts if any ?\n\nstg status -c does this but I don't have anything against refresh\nshowing it as well (can be made more general by modifying the\ncheck_conflicts function).\n\n> - patches/*/*.log branches could be better named as patchlogs/*/*\n> (easier to filter reliably)\n\nIt was easier to implement this way because the Patch objects have the\ndirectory where they store the commits. I also didn't want to polute\nthe refs directory with yet another directory.\n\n> - \"stg show\" should catch inexistant patch instead of saying \"Unknown\n> revision: that-patch^{commit}\"\n\nThis command works for commit ids as well as patches. If the patch\nisn't found, it considers the name to be a commit id.\n\n> - \"clean\" should give enough info for the user to locate any problem\n> (eg. conflict with files removed from revision control), eg. with a\n> \"popping to ...\" message\n\nClean only removes empty patches and there shouldn't be any conflicts\ncaused by this operation (unless there is a bug).\n\n> - \"stg fold\" should allow to pass -C to git-apply: context mismatch\n> currently makes folding unnecessarily hard\n\nMy solution was to leave a .stgit-failed.patch file which I apply\nmanually (I prefer to see what I apply rather than reducing the\ncontext information). Indeed, an option to fold would be nice.\n\n> - \"stg goto \" causes IndexError exception\n\nI thought it was fixed recently.\n\n> - \"sink\" or \"burry\" as opposite to \"float\" (possibly with a target\n> patch)\n\nBut how deep to burry it?\n\n> - lacks \"pick --patch=XXX\" to pick by name\n\nI don't understand this.\n\n> - interactive merge tools could only be called automatically after\n> failed merge, instead of requiring not-so-intuitive \"resolved -i\"\n\nYou can set the stgit.merger config option for this (diff3 followed by\nxxdiff or emacs). I even have a .py file for doing this, I can add it\nto the contrib dir. The other option would be to set this in the\nconfig file and move the handling of this operation to a common file\n(it can be used by all the operations involving a three-way merge)\n\n> - needs a config example to call ediff via gnuserv (possibly sending\n> several merges at a time, making use of the session registry)\n\nDon't know how to do it.\n\n> - shortcuts (st -> status, etc.), possibly making use of the git alias\n> system ?\n\nThis could be easily implemented in the main.py file by finding a\nsingle command match from the command list based on the first letters.\nIf more than one is found, just report the usual unknown command.\n\n> - \"stg fold\" should allow to run a merge (insert conflict markers, or\n> even just output a .rej patch somewhere)\n\nIt just calls git-apply. If this can do it, StGIT would use it.\n\n> - support for atomicity of complex transactions (stg begin/snapshot,\n> rollback, commit/finish - possibly with a transaction name so nesting would\n> just work)\n\nWould be nice but probably not that easy.\n\n> - mark patches as deactivated (float above all unapplied ones), so\n> even \"push -a\" would not push them\n\nThis would be good indeed.\n\n> - \"stg patches\" should be able to report on unapplied patches\n\nIt invokes GIT to find out the commits modifying the give file. An\nunapplied patch doesn't modify any local file.\n\n-- \n"},{"id":"296911","messageId":"200612101801.58247.jnareb@gmail.com","threadId":"6057","inReplyTo":"b0943d9e0612100831t7b79d4b1p436de5dbb813e51a@mail.gmail.com","subject":"Re: Collection of stgit issues and wishes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-10T17:01:58Z","receivedAt":"2006-12-10T17:01:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Catalin Marinas wrote:\n> On 10/12/06, Jakub Narebski wrote:\n>>>> Here are some issues which are a bit annoying for me:\n>>>> - make \"stg help\" (without command name) equivalent to \"stg --help\"\n> \n> There was a patch in this area. Doesn't it work correctly now?\n\nI use stgit 0.11\n\n1056:[gitweb/web!git]$ stg help\nusage: stg help \n\nwhile \"stg --help\" lists all commands.\n\n>>>> - stg new lacks --sign option (I have to remember to do this during\n>>>> \"stg refresh\").\n> \n> For that I use the .git/patchdescr.tmpl file to use as the initial\n> commit message. This has a Signed-off-by line.\n\nAh. I'm sorry, I haven't noticed this. It is\nin /usr/share/stgit/examples/\n\n>> And as far as I can see it doe not use git credentials (user.name and\n>> user.email).\n> \n> StGIT now uses the GIT credentials (and config files).\n\nHmmm... in stgit 0.11 \"stg refresh --sign\" once gave me Signed-off-by:\nNobody line instead of using git user.name and user.email.\n \n>> And yet another one: better support for reflog, namely giving the \"reason\"\n>> i.e. the reflog message (like \"stg push: \", \"stg refresh:\n>> \", \"stg pop: \", \"stg commit\" etc.), like git-rebase,\n>> git-commit --amend and git-am (for example) does.\n> \n> I had a patch doing this but I haven't included it. I considered it\n> was taking extra time for the push operation. I eventually added some\n> patch history support via the \"stg log\" command.\n\nThe git commands StGit uses to perform operations automatically record\nchanges in branches in reflog. What StGit does not provide is the \"reason\".\nYou do use git-update-ref?\n-- \nJakub Narebski\n"},{"id":"294973","messageId":"b0943d9e0612101426l763d46cahe15683410cb4398d@mail.gmail.com","threadId":"6057","inReplyTo":"200612101801.58247.jnareb@gmail.com","subject":"Re: Collection of stgit issues and wishes","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-12-10T22:26:44Z","receivedAt":"2006-12-10T22:26:44Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 10/12/06, Jakub Narebski wrote:\n> Catalin Marinas wrote:\n> > On 10/12/06, Jakub Narebski wrote:\n> >>>> Here are some issues which are a bit annoying for me:\n> >>>> - make \"stg help\" (without command name) equivalent to \"stg --help\"\n> >\n> > There was a patch in this area. Doesn't it work correctly now?\n>\n> I use stgit 0.11\n\nI was in general referring to the latest HEAD in the StGIT repository.\n\n>\n> 1056:[gitweb/web!git]$ stg help\n> usage: stg help \n>\n> while \"stg --help\" lists all commands.\n\nWorks correctly in the latest snapshot.\n\n> >> And as far as I can see it doe not use git credentials (user.name and\n> >> user.email).\n> >\n> > StGIT now uses the GIT credentials (and config files).\n>\n> Hmmm... in stgit 0.11 \"stg refresh --sign\" once gave me Signed-off-by:\n> Nobody line instead of using git user.name and user.email.\n\nAgain, it is different in the latest snapshot (feature added post 0.11).\n\n> The git commands StGit uses to perform operations automatically record\n> changes in branches in reflog. What StGit does not provide is the \"reason\".\n> You do use git-update-ref?\n\nYes, only for updating HEAD. The refs in refs/patches// are\nwritten directly. I initialy wanted to add patch history support using\nreflogs and added \"git-update-ref -m ...\" for the patch commits but I\nfound slow the pushing operation a bit. Do you only want to track the\nreflogs for HEAD?\n\n-- \n"},{"id":"294076","messageId":"200612110002.05847.jnareb@gmail.com","threadId":"6057","inReplyTo":"b0943d9e0612101426l763d46cahe15683410cb4398d@mail.gmail.com","subject":"Re: Collection of stgit issues and wishes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-10T23:02:05Z","receivedAt":"2006-12-10T23:02:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Catalin Marinas wrote:\n> On 10/12/06, Jakub Narebski wrote:\n\n>> The git commands StGit uses to perform operations automatically record\n>> changes in branches in reflog. What StGit does not provide is the \"reason\".\n>> You do use git-update-ref?\n> \n> Yes, only for updating HEAD. The refs in refs/patches// are\n> written directly. I initialy wanted to add patch history support using\n> reflogs and added \"git-update-ref -m ...\" for the patch commits but I\n> found slow the pushing operation a bit. Do you only want to track the\n> reflogs for HEAD?\n\nYes, I want for StGit to provide reasons when updating HEAD. I know that\nStGit manages it's own versioning of patches not using reflog -- fine.\nWhat matters for me is reflog for HEAD after \"stg commit; stg clean\".\n\n-- \nJakub Narebski\n"},{"id":"294227","messageId":"b0943d9e0612101524w3a2cccecqdd12023233e8ec0c@mail.gmail.com","threadId":"6057","inReplyTo":"200612110002.05847.jnareb@gmail.com","subject":"Re: Collection of stgit issues and wishes","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-12-10T23:24:32Z","receivedAt":"2006-12-10T23:24:32Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 10/12/06, Jakub Narebski wrote:\n> Catalin Marinas wrote:\n> > Yes, only for updating HEAD. The refs in refs/patches// are\n> > written directly. I initialy wanted to add patch history support using\n> > reflogs and added \"git-update-ref -m ...\" for the patch commits but I\n> > found slow the pushing operation a bit. Do you only want to track the\n> > reflogs for HEAD?\n>\n> Yes, I want for StGit to provide reasons when updating HEAD. I know that\n> StGit manages it's own versioning of patches not using reflog -- fine.\n> What matters for me is reflog for HEAD after \"stg commit; stg clean\".\n\nJust curious, do you run the \"stg commit; stg clean\" commands together\nand in this order? Neither of them would update the HEAD. The \"commit\"\ncommand simply removes the StGIT metadata for the applied patches\nsince it no longer needs to track them (permanently stored to the\nrepository). It doesn't change HEAD. The \"clean\" command only affects\nthe HEAD if there are empty applied patches but after a \"commit\" there\nwon't be any patches (only the unapplied ones which do not affect\nHEAD).\n\nMaybe we could have reflog info for \"push\", \"refresh\", some undo\noperations. Are they of any use (I haven't used them so I can't tell)?\n\n-- \n"},{"id":"295436","messageId":"200612110037.54309.jnareb@gmail.com","threadId":"6057","inReplyTo":"b0943d9e0612101524w3a2cccecqdd12023233e8ec0c@mail.gmail.com","subject":"Re: Collection of stgit issues and wishes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-10T23:37:54Z","receivedAt":"2006-12-10T23:37:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Catalin Marinas wrote:\n> On 10/12/06, Jakub Narebski wrote:\n>> Catalin Marinas wrote:\n>>> Yes, only for updating HEAD. The refs in refs/patches// are\n>>> written directly. I initialy wanted to add patch history support using\n>>> reflogs and added \"git-update-ref -m ...\" for the patch commits but I\n>>> found slow the pushing operation a bit. Do you only want to track the\n>>> reflogs for HEAD?\n>>\n>> Yes, I want for StGit to provide reasons when updating HEAD. I know that\n>> StGit manages it's own versioning of patches not using reflog -- fine.\n>> What matters for me is reflog for HEAD after \"stg commit; stg clean\".\n> \n> Just curious, do you run the \"stg commit; stg clean\" commands together\n> and in this order? Neither of them would update the HEAD. The \"commit\"\n> command simply removes the StGIT metadata for the applied patches\n> since it no longer needs to track them (permanently stored to the\n> repository). It doesn't change HEAD. The \"clean\" command only affects\n> the HEAD if there are empty applied patches but after a \"commit\" there\n> won't be any patches (only the unapplied ones which do not affect\n> HEAD).\n> \n> Maybe we could have reflog info for \"push\", \"refresh\", some undo\n> operations. Are they of any use (I haven't used them so I can't tell)?\n\nOoops, I haven't been clear enough.\n\nI meant that afer \"stg commit; stg clean\" I won't have any StGIT metadata,\nbut I'd have git metadata in reflog.\n\nI'd like to have info in reflog for each command which changes head;\nfor example \"push\", \"refresh\", perhaps \"pop\", \"float\", \"uncommit\".\nJust so I don't have long sequence of ref changes in reflog without\ndescription of said changes after some work with StGIT on branch.\n\n\nBTW. currently I use StGIT to manage a series of commits on feature\nbranch which implements step-by-step single feature, and would be\nlater send as a patch series. With StGIT I can work on final patch\nin series, notice that underlying feature developed in earlier patch\n(earlier commit) needs modification, so I do refresh, pop until\ngiven patch, change patch, push all, and work on patch. Or for example\nif I notice that I'd have to implement some basic feature separately,\nbest at beginning: pop all, create new patch etc. Very nice.\n\n-- \nJakub Narebski\n"},{"id":"298264","messageId":"b0943d9e0612110459y4009ce7fl44ceaa4bad33edf3@mail.gmail.com","threadId":"6057","inReplyTo":"200612110037.54309.jnareb@gmail.com","subject":"Re: Collection of stgit issues and wishes","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-12-11T12:59:01Z","receivedAt":"2006-12-11T12:59:01Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 10/12/06, Jakub Narebski wrote:\n> BTW. currently I use StGIT to manage a series of commits on feature\n> branch which implements step-by-step single feature, and would be\n> later send as a patch series. With StGIT I can work on final patch\n> in series, notice that underlying feature developed in earlier patch\n> (earlier commit) needs modification, so I do refresh, pop until\n> given patch, change patch, push all, and work on patch.\n\nOr, if you made a modification but you want it committed to an\nunderlying patch, use \"refresh --patch\" or \"pop --keep; refresh\".\n\nBTW, if it's not clear for me how to initially structure a patch\nseries, I add everything to a patch and create underlying patches\nafterwards and pick hunks from the big one (usually manually, though\nnative support in StGIT for this would be good, as someone pointed out\non this list). If all the hunks in the big patch were added to other\npatches, pushing the big one should result in an empty patch\nautomatically (because of the three-way merging) and can be safely\nremoved.\n\n-- \n"},{"id":"296509","messageId":"20061211184105.GC17132@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6057","inReplyTo":"200612110002.05847.jnareb@gmail.com","subject":"Re: Collection of stgit issues and wishes","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-12-11T18:41:05Z","receivedAt":"2006-12-11T18:41:05Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, Dec 11, 2006 at 12:02:05AM +0100, Jakub Narebski wrote:\n> Catalin Marinas wrote:\n> > On 10/12/06, Jakub Narebski wrote:\n> \n> >> The git commands StGit uses to perform operations automatically record\n> >> changes in branches in reflog. What StGit does not provide is the \"reason\".\n> >> You do use git-update-ref?\n> > \n> > Yes, only for updating HEAD. The refs in refs/patches// are\n> > written directly. I initialy wanted to add patch history support using\n> > reflogs and added \"git-update-ref -m ...\" for the patch commits but I\n> > found slow the pushing operation a bit. Do you only want to track the\n> > reflogs for HEAD?\n> \n> Yes, I want for StGit to provide reasons when updating HEAD.\n\nApart from the use-case you described in a later mail, this could\nprovide a path to series-level logging (one of the points in my list);\nsince the meaningful changes in a series involve changing the HEAD, we\nwould the have most the needed info that way.\n\nOperations just shuffling the stack (eg. \"float -s\", or \"push XXX;\npush --undo\") would probably require putting the series file itself\n"},{"id":"293845","messageId":"b0943d9e0612120143j7d0c1026rab046c8f44ec43ca@mail.gmail.com","threadId":"6057","inReplyTo":"20061208221744.GA3288@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Collection of stgit issues and wishes","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-12-12T09:43:52Z","receivedAt":"2006-12-12T09:43:52Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 08/12/06, Yann Dirson wrote:\n> - shortcuts (st -> status, etc.), possibly making use of the git alias\n> system ?\n\nDid this last night as it was pretty easy and without the GIT alias\nsystem (which I am not familiar with). The idea is that if it cannot\nfind an exact match, it tries to look for all the commands starting\nwith the passed argument. If more than one command is found, it\nreports an \"ambiguous command\".\n\n-- \n"},{"id":"298408","messageId":"elluik$ksq$1@sea.gmane.org","threadId":"6057","inReplyTo":"b0943d9e0612120143j7d0c1026rab046c8f44ec43ca@mail.gmail.com","subject":"Re: Collection of stgit issues and wishes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-12T10:02:11Z","receivedAt":"2006-12-12T10:02:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Catalin Marinas wrote:\n\n> On 08/12/06, Yann Dirson wrote:\n>> - shortcuts (st -> status, etc.), possibly making use of the git alias\n>> system ?\n> \n> Did this last night as it was pretty easy and without the GIT alias\n> system (which I am not familiar with). The idea is that if it cannot\n> find an exact match, it tries to look for all the commands starting\n> with the passed argument. If more than one command is found, it\n> reports an \"ambiguous command\".\n\nIsn't it better to use tab completion for that?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295413","messageId":"87y7pc2rc7.fsf@morpheus.local","threadId":"6057","inReplyTo":"b0943d9e0612120143j7d0c1026rab046c8f44ec43ca@mail.gmail.com","subject":"Re: Collection of stgit issues and wishes","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2006-12-13T07:22:00Z","receivedAt":"2006-12-13T07:22:00Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"\"Catalin Marinas\" writes:\n\n> On 08/12/06, Yann Dirson wrote:\n>> - shortcuts (st -> status, etc.), possibly making use of the git alias\n>> system ?\n>\n> Did this last night as it was pretty easy and without the GIT alias\n> system (which I am not familiar with). The idea is that if it cannot\n> find an exact match, it tries to look for all the commands starting\n> with the passed argument. If more than one command is found, it\n> reports an \"ambiguous command\".\n\nThat approach can cause problems later on. If \"stgit st\" is currently\na unique prefix of \"stgit status\", people might use it in scripts.\nThen, one day, you add the \"stgit store\" command, or whatever, and\ntheir scripts start breaking for no good reason.\n\n-- \nDavid Kågedal\n"},{"id":"298171","messageId":"457FD3E4.3090104@op5.se","threadId":"6057","inReplyTo":"87y7pc2rc7.fsf@morpheus.local","subject":"Re: Collection of stgit issues and wishes","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-13T10:20:20Z","receivedAt":"2006-12-13T10:20:20Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"David Kågedal wrote:\n> \"Catalin Marinas\" writes:\n> \n>> On 08/12/06, Yann Dirson wrote:\n>>> - shortcuts (st -> status, etc.), possibly making use of the git alias\n>>> system ?\n>> Did this last night as it was pretty easy and without the GIT alias\n>> system (which I am not familiar with). The idea is that if it cannot\n>> find an exact match, it tries to look for all the commands starting\n>> with the passed argument. If more than one command is found, it\n>> reports an \"ambiguous command\".\n> \n> That approach can cause problems later on. If \"stgit st\" is currently\n> a unique prefix of \"stgit status\", people might use it in scripts.\n> Then, one day, you add the \"stgit store\" command, or whatever, and\n> their scripts start breaking for no good reason.\n> \n\nPeople who use abbreviations of commands in scripts ought to be shot, \nnot catered to, especially if they know this abbreviation is \nautomagically calculated.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"295752","messageId":"20061213110314.GA22670@diana.vm.bytemark.co.uk","threadId":"6057","inReplyTo":"457FD3E4.3090104@op5.se","subject":"Re: Collection of stgit issues and wishes","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-12-13T11:03:14Z","receivedAt":"2006-12-13T11:03:14Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-12-13 11:20:20 +0100, Andreas Ericsson wrote:\n\n> David Kågedal wrote:\n>\n> > \"Catalin Marinas\" writes:\n> >\n> > > On 08/12/06, Yann Dirson wrote:\n> > >\n> > > > - shortcuts (st -> status, etc.), possibly making use of the\n> > > > git alias system ?\n> > >\n> > > Did this last night as it was pretty easy and without the GIT\n> > > alias system (which I am not familiar with). The idea is that if\n> > > it cannot find an exact match, it tries to look for all the\n> > > commands starting with the passed argument. If more than one\n> > > command is found, it reports an \"ambiguous command\".\n> >\n> > That approach can cause problems later on. If \"stgit st\" is\n> > currently a unique prefix of \"stgit status\", people might use it\n> > in scripts. Then, one day, you add the \"stgit store\" command, or\n> > whatever, and their scripts start breaking for no good reason.\n>\n> People who use abbreviations of commands in scripts ought to be\n> shot, not catered to, especially if they know this abbreviation is\n> automagically calculated.\n\nWell, yes, but there's no reason to not shoot them _politely_ ...\n\nI'd prefer hand-picked command abbreviations to reduce namespace\nclutter. That way, it's even possible to have \"ambiguous\" shortcuts --\nfor example, \"stg st\" -> \"stg status\" even if \"stg store\" exists. And\nshortcuts that aren't prefixes, like \"stg ua\" -> \"stg unapplied\". And\nthe user doesn't need to retrain her fingers just because a prefix\ngets ambiguous.\n\nFor prefixes, tab completion is a much better answer.\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"294385","messageId":"b0943d9e0612131414h25a75bf8h14b5a1731ea47afb@mail.gmail.com","threadId":"6057","inReplyTo":"20061211184105.GC17132@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Collection of stgit issues and wishes","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-12-13T22:14:32Z","receivedAt":"2006-12-13T22:14:32Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 11/12/06, Yann Dirson wrote:\n> Operations just shuffling the stack (eg. \"float -s\", or \"push XXX;\n> push --undo\") would probably require putting the series file itself\n> under version-control.\n\nIt depends on the numver of undos allowed. With only one, you could\nhave a series.old file or similar.\n\nI'll try to add a wiki page with todo/wishlist ideas and prioritise\nthose included before 1.0. Post 1.0, I'll try to look at changing the\nrepository layout a bit to reduce the amount of metadata and also\nfacilitate the support for transactions etc.\n\n-- \n"},{"id":"297505","messageId":"20061217231540.GB16838@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6057","inReplyTo":"b0943d9e0612100825h3ef2fa77kd5d9fd5022cbb3f9@mail.gmail.com","subject":"Re: Collection of stgit issues and wishes","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-12-17T23:15:40Z","receivedAt":"2006-12-17T23:15:40Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sun, Dec 10, 2006 at 04:25:52PM +0000, Catalin Marinas wrote:\n> Since this list gets changed pretty often, I would rather add TODO\n> Bugs wiki pages on http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT\n\nGreat idea.\n\n> (maybe I should create a page on one of the open-source hosting sites\n> and get some bug-tracking support).\n\nIf you're only looking for bugtracking, I wonder whether\nbugzilla.kernel.org could be used (as well as for core git and other\ngit-related tools). Or maybe a new git-specialized bugzilla could be\nsetup somewhere ?\n\nBTW, and a bit off-topic, one thing that would be great to have would be\ngit-bugzilla coupling (mainly, recording into bugzilla when a commit\naddressing an issue gets pushed to an official tree).\nScmbug already provides a framework for such couplings, and already has\nbugilla/mantis/RT support on the BTS side.\n\n\n> I keep the TODO file mainly for\n> what I plan to implement and, while I agree with many of the issues\n> you point below, I don't guarantee I have time to fix/implement.\n\nI tend do that myself too - in fact, a number of the issues I reported\nare candidates for future patches from me :)\n\n\n> >- \"stg import\" leaves empty patch on the stack after failed patch \n> >application\n> \n> That's a feature in the sense that it creates the empty patch with the\n> description and author information. It also leaves a\n> .stgit-failed.patch which you can manually apply.\n\nI was not aware of this. It would be useful to tell the user when such\na failed patch is left behind (that would have saved me some timing\nalready ;).\n\n\n> >- \"patches -d\" may be confused by files added then removed (below,\n> >file added to platform-v0, removed in rm-junk, problem encountered on\n> >2006-08-14, probably on 0.10):\n> \n> Is this still the case now? I fixed a similar issue a few months ago\n> (commit a57bd72016d3cf3ee8e8fd7ae2c12e047999b602; GIT considers a file\n> name to be revision name if the file isn't found on disk; easily\n> fixable by adding the \"--\" separator).\n\nI should check.\n\n\n> >- \"stg show\" should catch inexistant patch instead of saying \"Unknown\n> >revision: that-patch^{commit}\"\n> \n> This command works for commit ids as well as patches. If the patch\n> isn't found, it considers the name to be a commit id.\n\nOK. Then some message like \"No patch or commit id found matching\n$commit\" could be more informative.\n\n\n> >- \"clean\" should give enough info for the user to locate any problem\n> >(eg. conflict with files removed from revision control), eg. with a\n> >\"popping to ...\" message\n> \n> Clean only removes empty patches and there shouldn't be any conflicts\n> caused by this operation (unless there is a bug).\n\nI have already described the problem in a previous thread. There is a\nconflict when a generated file gets committed by error, and then a stgit\npatch removes it. If one tries to pop that patch when the generated\nfile exists, there is a conflict.\n\n\n> >- \"sink\" or \"burry\" as opposite to \"float\" (possibly with a target\n> >patch)\n> \n> But how deep to burry it?\n\nI'd think to bottom of stack by default (mostly to get a sane default),\nbut with an option to specify the position.\nOr maybe as \"stg bury-below \".\n\n> >- lacks \"pick --patch=XXX\" to pick by name\n> \n> I don't understand this.\n\nHm, I must have been confused, just ignore.\n\n\n> >- interactive merge tools could only be called automatically after\n> >failed merge, instead of requiring not-so-intuitive \"resolved -i\"\n> \n> You can set the stgit.merger config option for this (diff3 followed by\n> xxdiff or emacs). I even have a .py file for doing this, I can add it\n> to the contrib dir.\n\nWhat about automatically triggering stgit.imerger when stgit.merger\nfailed ?\n\n\n> >- needs a config example to call ediff via gnuserv (possibly sending\n> >several merges at a time, making use of the session registry)\n> \n> Don't know how to do it.\n\nThat's one of the TODO items directed at myself (unless some good soul\ntakes care of that first ;)\n\n\n> >- \"stg fold\" should allow to run a merge (insert conflict markers, or\n> >even just output a .rej patch somewhere)\n> \n> It just calls git-apply. If this can do it, StGIT would use it.\n\nI still have to invest some time into the available merge algorithms.\nIf nothing is available yet for this, we shall find out how to do it :)\n\n\n> >- support for atomicity of complex transactions (stg begin/snapshot,\n> >rollback, commit/finish - possibly with a transaction name so nesting would\n> >just work)\n> \n> Would be nice but probably not that easy.\n\nFull logging of series file would help, I think. Once we have full\nlogging of the stack, we get cheap transactions as well as arbitrary\nundo depth, and the \"stg undo\" command to replace all those --undo\nflags. But right, it still requires some work :)\n\n\n> >- \"stg patches\" should be able to report on unapplied patches\n> \n> It invokes GIT to find out the commits modifying the give file. An\n> unapplied patch doesn't modify any local file.\n\nRight, but I think we could invoke GIT to report on each of the unapplied\npatches that form a head, and restrict the output to those commits that\nare stgit patches.\n\nBest regards,\n-- \n"},{"id":"295477","messageId":"20061217232113.GC16838@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6057","inReplyTo":"20061213110314.GA22670@diana.vm.bytemark.co.uk","subject":"Re: Collection of stgit issues and wishes","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-12-17T23:21:14Z","receivedAt":"2006-12-17T23:21:14Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Wed, Dec 13, 2006 at 12:03:14PM +0100, Karl Hasselstr?m wrote:\n> > > That approach can cause problems later on. If \"stgit st\" is\n> > > currently a unique prefix of \"stgit status\", people might use it\n> > > in scripts. Then, one day, you add the \"stgit store\" command, or\n> > > whatever, and their scripts start breaking for no good reason.\n\nSuch shortcuts are *definitely* not for script writers.\n\n> > People who use abbreviations of commands in scripts ought to be\n> > shot, not catered to, especially if they know this abbreviation is\n> > automagically calculated.\n> \n> Well, yes, but there's no reason to not shoot them _politely_ ...\n\nAt least we could shoot them when stdout is not a tty ?\nNot sure there is a good way of detecting if we're being run directly \nfrom an interactive shell.\n\n\n> I'd prefer hand-picked command abbreviations to reduce namespace\n> clutter. That way, it's even possible to have \"ambiguous\" shortcuts --\n> for example, \"stg st\" -> \"stg status\" even if \"stg store\" exists. And\n> shortcuts that aren't prefixes, like \"stg ua\" -> \"stg unapplied\". And\n> the user doesn't need to retrain her fingers just because a prefix\n> gets ambiguous.\n\nSure, I'd hate having to type \"stg sta\" :)\n\nBest regards,\n-- \n"},{"id":"29937","messageId":"emdrl2$bkl$1@sea.gmane.org","threadId":"6057","inReplyTo":"b0943d9e0612110459y4009ce7fl44ceaa4bad33edf3@mail.gmail.com","subject":"Re: Collection of stgit issues and wishes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-21T11:39:45Z","receivedAt":"2006-12-21T11:39:45Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: git@vger.kernel.org]\n\nCatalin Marinas wrote:\n\n> BTW, if it's not clear for me how to initially structure a patch\n> series, I add everything to a patch and create underlying patches\n> afterwards and pick hunks from the big one (usually manually, though\n> native support in StGIT for this would be good, as someone pointed out\n> on this list). If all the hunks in the big patch were added to other\n> patches, pushing the big one should result in an empty patch\n> automatically (because of the three-way merging) and can be safely\n> removed.\n\nPerhaps this calls for \"stg duplicate\" command, which would result\nin duplicating patch (perhaps one would need to provide name for\nthe first patch, and optionally laso for second patch) in such way\nthat first copy would be on top of aplied stack, and second copy\n(the duplicate, with an old name) would be at the bottom of the deck\nof unapplied patches.\n\nThis way if you want to for example split patch into two, you would\ndo\n\n$ stg duplicate new-name\n$ edit files\n$ stg refresh\n$ stg push\n\nAnd similarly (with more duplicates) if you want to split it more.\n\nWhat do you think about this?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29976","messageId":"emf6bp$2l9$1@sea.gmane.org","threadId":"6057","inReplyTo":"b0943d9e0612131414h25a75bf8h14b5a1731ea47afb@mail.gmail.com","subject":"Re: Collection of stgit issues and wishes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-21T23:48:46Z","receivedAt":"2006-12-21T23:48:46Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Catalin Marinas wrote:\n\n> I'll try to add a wiki page with todo/wishlist ideas and prioritise\n> those included before 1.0. Post 1.0, I'll try to look at changing the\n> repository layout a bit to reduce the amount of metadata and also\n> facilitate the support for transactions etc.\n\nWhat about this page? Not found on\n http://wiki.procode.org/cgi-bin/wiki.cgi?action=index\n\nBy the way, it would be nice to be able to put in cover mail template the\nfollowing variables:\n * %(patches)s - list of patch names, each in one line, '* ' prefixed\n * %(patchesdescr)s - list of patch %(shortdescr)s, the first line\n of the patch description, shortlog-like word-wrapped, perhaps with,\n perhaps without [PATCH m/n] prefix.\n * %(diffstat) - diff statistics of first and last patch, only if\n there are no gaps in patches provided nor patch reordering\n (single patch, single range, or -a)\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}