{"thread":{"id":"8171","subject":"[StGIT RFC] Changing patch@branch syntax","startedAt":"2007-05-15T22:03:10Z","lastAt":"2007-07-06T22:04:06Z","messageCount":12,"participants":["Yann Dirson","Karl Hasselström","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"42254","messageId":"20070515220310.GJ16903@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8171","inReplyTo":null,"subject":"[StGIT RFC] Changing patch@branch syntax","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-15T22:03:10Z","receivedAt":"2007-05-15T22:03:10Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"The patch@branch syntax is annoying, at least for bash-completion\npurposes: we don't want to provide all possible completions accross\nall branches, yet we'd like to get completion for foreign patches.\n\nAnother place where I feel it is bad is when using the full\n\"patch@branch//top\" syntax: the MSB is in the middle, and the LSB is\non the right.\n\nBoth issues would be solved by switching to a MSB ordering, with a way\nto distinguish branchnames when given. Something similar to pathnames\nwould fit well - eg. [/branchname/]patchname[//top]. However, I'm not\nsure using slashes would be a good choice, precisely because of the\nsimilarity with real pathnames. But we don't have so many separator\nchars that are not special in one way or another, and would require\nquoting them to avoid more user confusion.\n\nWhat do you think ?\n-- \nYann.\n"},{"id":"42297","messageId":"20070516065438.GA7453@diana.vm.bytemark.co.uk","threadId":"8171","inReplyTo":"20070515220310.GJ16903@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [StGIT RFC] Changing patch@branch syntax","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-16T06:54:38Z","receivedAt":"2007-05-16T06:54:38Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-16 00:03:10 +0200, Yann Dirson wrote:\n\n> The patch@branch syntax is annoying, at least for bash-completion\n> purposes: we don't want to provide all possible completions accross\n> all branches, yet we'd like to get completion for foreign patches.\n\nYes, that's annoying.\n\n> Another place where I feel it is bad is when using the full\n> \"patch@branch//top\" syntax: the MSB is in the middle, and the LSB is\n> on the right.\n\nI agree. (Similarly, YYYYMMDD is the one true date format!)\n\n> Both issues would be solved by switching to a MSB ordering, with a\n> way to distinguish branchnames when given. Something similar to\n> pathnames would fit well - eg. [/branchname/]patchname[//top].\n> However, I'm not sure using slashes would be a good choice,\n> precisely because of the similarity with real pathnames. But we\n> don't have so many separator chars that are not special in one way\n> or another, and would require quoting them to avoid more user\n> confusion.\n\nBranch names can contain slashes, and in the future patch names might\nas well, so we'd need another separator. _Except_ for the fact that if\nfoo/bar is a branch, foo/bar/baz can't also be a branch, so using a\nslash as separator is actually unambiguous.\n\nIf we similarly make it illegal for patches a/b and a/b/c to exist\nsimultaneously (whenever we get around to implementing slashy patch\nnames), we could use a single slash for patchname/{top,bottom} too.\n\nThe only remaining difficulty is to decide whether a/b/c is patch b/c\non branch a, or patch a/b/c on the current branch. We can't forbid\npatch names and branch names to collide, since git can create new\nbranch names behind stgit's back. So I guess we'd need some way to\nindicate whether branch name is included. The leading slash in your\nsuggestion seems as good a way as any.\n\nHowever, I'm not going to recommend using only slashes. I believe life\nwill be much simpler if we simply use two different separators, like\nthis:\n\n branch:patch@top\n\nThen all these subsets will be trivially parseable:\n\n branch:patch\n\n patch\n\n patch@top\n\nAnd even this one, if we feel crazy some day:\n\n /path/to/other/repository#branch:patch@top\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"42973","messageId":"b0943d9e0705220527x5d4c3d0fw2d0d66b37aab3f97@mail.gmail.com","threadId":"8171","inReplyTo":"20070515220310.GJ16903@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [StGIT RFC] Changing patch@branch syntax","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-05-22T12:27:08Z","receivedAt":"2007-05-22T12:27:08Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 15/05/07, Yann Dirson wrote:\n> The patch@branch syntax is annoying, at least for bash-completion\n> purposes: we don't want to provide all possible completions accross\n> all branches, yet we'd like to get completion for foreign patches.\n>\n> Another place where I feel it is bad is when using the full\n> \"patch@branch//top\" syntax: the MSB is in the middle, and the LSB is\n> on the right.\n\nI agree that the current syntax is bad.\n\n> Both issues would be solved by switching to a MSB ordering, with a way\n> to distinguish branchnames when given. Something similar to pathnames\n> would fit well - eg. [/branchname/]patchname[//top]. However, I'm not\n> sure using slashes would be a good choice, precisely because of the\n> similarity with real pathnames. But we don't have so many separator\n> chars that are not special in one way or another, and would require\n> quoting them to avoid more user confusion.\n\nWe had a discussion some time ago about using slashes for the //top or\n//bottom syntax and we ended up using two slashes. We could do the\nsame to delimitate the branch from the patch - branch//patch//top. The\nbranch or patch can have (single) slashes in their name.\n\nWe couldn't use \":\" at that time as it was used for the 'diff -r x:y'\ncommand. I later switched to the git \"..\" format (when git eventually\ndefined it). As Karl said, branch:patch@top is another way, unless we\nlater decide to add another level, the repository, and would like to\nhave a uniform syntax (maybe always use \":\" instead of \"//\"). We could\nrun commands like:\n\n stg pick ../../path/to/linux-repo//branch//patch\n\nI don't think using \"#\" is feasible as bash ignores everything after\nit unless you use quotes or escape.\n\nAnother nice thing to have is a way to get older versions of a patch\nvia patchlogs. This should probably follow the current git notation,\ni.e. patch^^^ or patch~N.\n\n-- \nCatalin\n"},{"id":"42989","messageId":"20070522210020.GV19253@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8171","inReplyTo":"b0943d9e0705220527x5d4c3d0fw2d0d66b37aab3f97@mail.gmail.com","subject":"Re: [StGIT RFC] Changing patch@branch syntax","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-22T21:00:20Z","receivedAt":"2007-05-22T21:00:20Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Tue, May 22, 2007 at 01:27:08PM +0100, Catalin Marinas wrote:\n> We had a discussion some time ago about using slashes for the //top or\n> //bottom syntax and we ended up using two slashes. We could do the\n> same to delimitate the branch from the patch - branch//patch//top. The\n> branch or patch can have (single) slashes in their name.\n> \n> We couldn't use \":\" at that time as it was used for the 'diff -r x:y'\n> command. I later switched to the git \"..\" format (when git eventually\n> defined it). As Karl said, branch:patch@top is another way, unless we\n> later decide to add another level, the repository, and would like to\n> have a uniform syntax (maybe always use \":\" instead of \"//\"). We could\n> run commands like:\n> \n> stg pick ../../path/to/linux-repo//branch//patch\n\nIndeed I would possibly already have used this if it had been\navailable (working with 2 working copies for 2 cvs branches of a\nsingle project, using stg-cvs in each).\n\n\n> I don't think using \"#\" is feasible as bash ignores everything after\n> it unless you use quotes or escape.\n\nNo, bash only considers # as a comment leader if there is space before\nit, which would not be the case here (and is why the\nhttp://repo#branch in cogito worked without problems). Not sure about\nother shells, though.\n\nI'm not very comfortable with // either, since having it special makes\nit harder for script writers (need to canonicalize dirnames to ensure\na double slash is not inserted by error). Whereas it's not a big\nproblem to solve when the script writer is aware of the problem, it's\nnot something everyone would think about, and it may even break\nexisting scripts.\n\n\nFollowing the \"stg pick\" example above, would we also want to allow\npicking from a remote repo ? Then the URL fragment notation could be\nsuited, and we could have something like:\n\n\thttp://full/path/to/repo#my/branch:my/patch//top\n\nThat is, a formal syntax of:\n\n\t[[[repo#]branch:]patch][//modifier]\n\nGoing further, since specifying a repo without a branch probably has\nno meaning (unless we want to default to the HEAD branch), we could\nsimplify to the following:\n\n\t[[[repo#]branch#]patch][//modifier]\n\nI don't think we really want to allow \"repo#patch\", meaning that patch\non the current branch, as this gets easily confused by branch switching.\n\n\n> Another nice thing to have is a way to get older versions of a patch\n> via patchlogs. This should probably follow the current git notation,\n> i.e. patch^^^ or patch~N.\n\nYes, that's something I've thought about several times, without coming\nwith a satisfying solution either: using the git notation to refer to\nsomething different is not a good idea (we already have a \"push\"\ncommand with a completely different meaning, let's keep these beasts\nout if possible ;). There is already another syntax used by git for\nreflogs (ref@{N}), which would have the same problem.\n\nWe should also keep in mind that someday we'll surely have merge\nentries in patchlogs (one of the things near the top of my todo list),\nso the same facility available in git for commit parents as ref^N will\nbe useful as well.\n\nAnother thing is, it would be great if the syntax we elect for this\nwould be \"reserved\" by git-core, so git-core does not start to use it\none day and cause a conflict. Maybe it could be \"reserved\" so other\nporcelains can as well use it (yes, there is the problem of how those\nother porcelains interact with stgit then - or rather, how will we\nhelp the user not to get confused) ?\n\nBest regards,\n-- \nYann.\n"},{"id":"45530","messageId":"20070621230207.GD7730@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8171","inReplyTo":"20070522210020.GV19253@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [StGIT RFC] Changing patch@branch syntax","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-06-21T23:02:07Z","receivedAt":"2007-06-21T23:02:07Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"Working in the implementation of hydras/pools, as well as discussing\nof their future, led me to the following thoughts, quite related to\nhow we should select a new syntax for patches.\n\nFirst, as a foreword, a bit if refactoring: I think we should use some\nsort of Stackable (maybe pick a better name) class as a parent for\nPatch and PatchSet. Instances of a Stackable would be candidates to\nbe members of a PatchSet. That means we can have stacks within a\nstack, as well as stacks members of a pool. But we also need a syntax\nto name stacks-(in-a-stack)*, and patches within them.\n\nSecond, but not least, we currently have an ambiguity in syntax: \"foo\"\ncan mean \"patch foo in current branch\" or \"branch foo\", depending on\nthe context, and that is *really* bad. What's more, my former\nproposal (quoted below) does not improve this issue. And my previous\nproposal, which suggested using a prefix like \"/stack/patch\" for a\nfully qualified patch and \"patch\" for a relative one does not solve\nthat problem either, and brings the additional annoyance of\nintroducing a syntax that is incompatible with git-core.\n\nSo here is a new proposal, which I believe would address all current\nissues, at the expense of changing stgit syntax. The idea is to use a\nsingle separator for all levels of Stackable objects, with an optional\n\"patch id\" (eg. //top) at the end when meaningful. Only names would\nbe possible to omit, separators would be mandatory to specify the\nnesting level. That gives a syntax of:\n\n\t[patchset]([:stackable]+(//id)?)*\n\nExamples:\n\n\t\t\t\tthe named branch (git-compatible)\n\t:\t\tnamed patch in named stack\n\t:\t\tnamed patch in current patchset (currently just \"\")\n\t:\t\tcurrent (top) patch in named patchset\n\t::\tfully-qualified patch in a named hydra\n\t::\t\t\ttop patch of the current stack of an hydra\n\t:://bottom.old\tprevious bottom of the top patch in the named stack of current pool\n\n\nHow does that feel ?\n\n\nOn Tue, May 22, 2007 at 11:00:20PM +0200, Yann Dirson wrote:\n> Following the \"stg pick\" example above, would we also want to allow\n> picking from a remote repo ? Then the URL fragment notation could be\n> suited, and we could have something like:\n> \n> \thttp://full/path/to/repo#my/branch:my/patch//top\n> \n> That is, a formal syntax of:\n> \n> \t[[[repo#]branch:]patch][//modifier]\n> \n> Going further, since specifying a repo without a branch probably has\n> no meaning (unless we want to default to the HEAD branch), we could\n> simplify to the following:\n> \n> \t[[[repo#]branch#]patch][//modifier]\n> \n> I don't think we really want to allow \"repo#patch\", meaning that patch\n> on the current branch, as this gets easily confused by branch switching.\n"},{"id":"45577","messageId":"b0943d9e0706220859n2c2962ffy21464526a5ebd6cd@mail.gmail.com","threadId":"8171","inReplyTo":"20070621230207.GD7730@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [StGIT RFC] Changing patch@branch syntax","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-06-22T15:59:05Z","receivedAt":"2007-06-22T15:59:05Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 22/06/07, Yann Dirson wrote:\n> First, as a foreword, a bit if refactoring: I think we should use some\n> sort of Stackable (maybe pick a better name) class as a parent for\n> Patch and PatchSet. Instances of a Stackable would be candidates to\n> be members of a PatchSet. That means we can have stacks within a\n> stack, as well as stacks members of a pool. But we also need a syntax\n> to name stacks-(in-a-stack)*, and patches within them.\n\nI'm OK with refactoring the code this way (the current code is based\non the initial prototype but it evolved a lot since then).\n\n> So here is a new proposal, which I believe would address all current\n> issues, at the expense of changing stgit syntax. The idea is to use a\n> single separator for all levels of Stackable objects, with an optional\n> \"patch id\" (eg. //top) at the end when meaningful. Only names would\n> be possible to omit, separators would be mandatory to specify the\n> nesting level. That gives a syntax of:\n>\n> [patchset]([:stackable]+(//id)?)*\n\nI don't think I can write a regexp for it but I don't like the\nmandatory \":\" before the patch name (or stackable object). The main\nreason is that one usually works on a branch with patch names, there\nmight be scripts+xargs involved and forcing the use of \":\" would make\nit more complicated.\n\nI also don't think we need to make this distinction in the names as\ndifferent commands or options take different type of arguments:\n\nstg show \nstg series --branch \n\nI'll try to express this with BNF (though I'm not an expert in this notation):\n\n ::= \"\" | [^\\w.-]+\n ::= top | top.old | bottom | bottom.old | log | ...\n ::= | //\n\n ::= | :\n\nIf empty name (\"\"), the current object for the level is used.\n\nThe above is more generic. A patchset might have other\nattributes or none at all (could have a \"old\" attribute if we decide\nto keep older versions of a stack for example).\n\nIn terms of our patches, stacks etc.:\n\n ::= \n ::= | :\n ::= | :\n\nI would introduce a in front of all the above (for which we\ndon't have any support) but this is somehow at a similar level to\n in case we don't use a hydra. Or the can also be a\nrepository?\n\n> Examples:\n>\n> the named branch (git-compatible)\n\n - named patch in the current patchset\n\n> : named patch in named stack\n\nOK\n\n> : named patch in current patchset (currently just \"\")\n\nOK, the same as \n\n> : current (top) patch in named patchset\n\nOK (maybe use should use \"current\" rather than \"top\" in the\ndescription as it applies better to other stackable objects)\n\n> :: fully-qualified patch in a named hydra\n\nOK\n\n> :: top patch of the current stack of an hydra\n\nOK (current patch of the current stack)\n\n> :://bottom.old previous bottom of the top patch in the named stack of current pool\n\nOK\n\n-- \nCatalin\n"},{"id":"45580","messageId":"20070622200037.GE7730@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8171","inReplyTo":"b0943d9e0706220859n2c2962ffy21464526a5ebd6cd@mail.gmail.com","subject":"Re: [StGIT RFC] Changing patch@branch syntax","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-06-22T20:00:37Z","receivedAt":"2007-06-22T20:00:37Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Jun 22, 2007 at 04:59:05PM +0100, Catalin Marinas wrote:\n> >So here is a new proposal, which I believe would address all current\n> >issues, at the expense of changing stgit syntax. The idea is to use a\n> >single separator for all levels of Stackable objects, with an optional\n> >\"patch id\" (eg. //top) at the end when meaningful. Only names would\n> >be possible to omit, separators would be mandatory to specify the\n> >nesting level. That gives a syntax of:\n> >\n> > [patchset]([:stackable]+(//id)?)*\n> \n> I don't think I can write a regexp for it but I don't like the\n> mandatory \":\" before the patch name (or stackable object). The main\n> reason is that one usually works on a branch with patch names, there\n> might be scripts+xargs involved and forcing the use of \":\" would make\n> it more complicated.\n\nThat's probably not much of a problem: patch lists could be generated\nfor script use with a flag similar to \"series --showbranch\".\n\n\n> I also don't think we need to make this distinction in the names as\n> different commands or options take different type of arguments:\n> \n> stg show \n> stg series --branch \n\nCurrently, \"stg show HEAD\" or any other git ref does work, except when\nthere are name clashes.\n\nAnd since we're going to have all of patches, stacks, and pools in the\nsame \"stackable\" family, we're going to use them interchangeably in\nmore and more places. But there are also places where we can use at\nwill stack names and generic git heads (eg. \"stg branch X\").\n\nI'd rather having a single name-resolution mechanism, instead of one\nfor patches and one for branches.\n\n\n> I'll try to express this with BNF (though I'm not an expert in this \n> notation):\n> \n> ::= \"\" | [^\\w.-]+\n> ::= top | top.old | bottom | bottom.old | log | ...\n> ::= | //\n> \n> ::= | :\n> \n> If empty name (\"\"), the current object for the level is used.\n> \n> The above is more generic. A patchset might have other\n> attributes or none at all (could have a \"old\" attribute if we decide\n> to keep older versions of a stack for example).\n\nRight, good idea.\n\n\n> I would introduce a in front of all the above (for which we\n> don't have any support)\n\nYes - URLs could do the work, with a '#' to use the stackable as URL\nfragment.\n\n\n> but this is somehow at a similar level to in case we don't\n> use a hydra. Or the can also be a repository?\n\nI think they are different enough: a pool/hydra typically has several\nmembers applied, whereas a repo has only a current branch.\n\n\n\nNow for technical details. I have a prototype hydra mechanism that\ndemonstrates that we can create such a beast without having everything\nbreaking all around. However, it does not use the model described in\nthis thread, but rather links to stacks which exist independantly - I\nwant to keep that as a possibility, by using some symlink-like\nmechanism, but the current prototype will not live, although I may\nexperiment a bit more with it. BTW, we should probably name the final\nbeast \"pool\" and not \"hydra\", so users have a better idea of how to\nuse it :)\n\nHowever, the various refactorings and fixes I have done should be\nquite ready for inclusion (modulo dispatching recent fixes down to the\nrelevant patch). Here I need to know your plans for 0.13: if the\nrefactoring would go in, I just have to polish things as they are; if\nyou prefer to keep this for 0.14, I'll sink the bugfixes down my stack\nso they can be in 0.13 at least.\n\nDid you have time to look at the various refactorings at\nhttp://repo.or.cz/w/stgit/ydirson.git ?\n\nBest regards,\n-- \nYann\n"},{"id":"45584","messageId":"b0943d9e0706221529w63a41e82r557179a45b461f61@mail.gmail.com","threadId":"8171","inReplyTo":"20070622200037.GE7730@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [StGIT RFC] Changing patch@branch syntax","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-06-22T22:29:14Z","receivedAt":"2007-06-22T22:29:14Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 22/06/07, Yann Dirson wrote:\n> On Fri, Jun 22, 2007 at 04:59:05PM +0100, Catalin Marinas wrote:\n> > I also don't think we need to make this distinction in the names as\n> > different commands or options take different type of arguments:\n> >\n> > stg show \n> > stg series --branch \n>\n> Currently, \"stg show HEAD\" or any other git ref does work, except when\n> there are name clashes.\n\nBut the argument to 'show' here is either a patch or a git ref (not a\nstack or a pool). It first tries to find a patch and fall back to a\ngit ref. You don't specify a stack to 'show'. 'git show' is also able\nto take a commit or a tag object without clearly specifying the\ndifference.\n\nWhat might be easier with a complete spec is bash completion. I find\nthis mandatory precise description similar to the Hungarian notation.\nSince most of the time I work with push/pop commands, I don't like\nalways putting a \":\" for every patch (BTW, what about patch ranges, I\ndon't think they can go across multiple stacks).\n\n> And since we're going to have all of patches, stacks, and pools in the\n> same \"stackable\" family, we're going to use them interchangeably in\n> more and more places. But there are also places where we can use at\n> will stack names and generic git heads (eg. \"stg branch X\").\n\nCurrently, stack names and git branches are the same. Would this\nchange with hydra? I use StGIT to maintain my branches on\nhttp://www.linux-arm.org/git?p=linux-2.6.git;a=heads and I find the\nstack name == git branch simplification pretty useful.\n\nWhat commands/options would we have where we need to distinguish\nbetween stack and patch names?\n\n> I'd rather having a single name-resolution mechanism, instead of one\n> for patches and one for branches.\n\nI don't see why we couldn't have a single name resolution but without\nthe mandatory \":\". An example (but in reverse order) is internet\nnames. I only type \"intranet\" rather than \"intranet.\" in a browser. To\nfully qualify, I type \"intranet.arm.com\".\n\n> > I would introduce a in front of all the above (for which we\n> > don't have any support)\n>\n> Yes - URLs could do the work, with a '#' to use the stackable as URL\n> fragment.\n\nOK, you mentioned this in the past.\n\n> Now for technical details. I have a prototype hydra mechanism that\n> demonstrates that we can create such a beast without having everything\n> breaking all around. However, it does not use the model described in\n> this thread, but rather links to stacks which exist independantly - I\n> want to keep that as a possibility, by using some symlink-like\n> mechanism, but the current prototype will not live, although I may\n> experiment a bit more with it. BTW, we should probably name the final\n> beast \"pool\" and not \"hydra\", so users have a better idea of how to\n> use it :)\n\nYes, \"pool\" sounds better (though I didn't get the full idea of how\nthings work).\n\n> However, the various refactorings and fixes I have done should be\n> quite ready for inclusion (modulo dispatching recent fixes down to the\n> relevant patch). Here I need to know your plans for 0.13: if the\n> refactoring would go in, I just have to polish things as they are; if\n> you prefer to keep this for 0.14, I'll sink the bugfixes down my stack\n> so they can be in 0.13 at least.\n\nI plan to do a 0.13 release pretty soon. I want to clear some of the\nlogged bugs and release it as it seems to be pretty stable. It's\nbetter to keep this refactoring for 0.14.\n\nIf it is easier for you, you could create a branch (for-upstream etc.)\nand just send me an email to merge it.\n\n> Did you have time to look at the various refactorings at\n> http://repo.or.cz/w/stgit/ydirson.git ?\n\nI had a quick look (not much though, moving house and a lot of FYI).\nThey look OK, but just a few comments:\n\n- concreteCommand, I would write classes with capital first letter\n(unwritten convention in StGIT)\n\n- why the Repository class definition in stgit/__init__.py? Can it not\nbe in a different file? Also, shourt stgit/git.py be aware of the\nrepository?\n\nRegards.\n\n-- \nCatalin\n"},{"id":"45695","messageId":"20070624212603.GA6361@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8171","inReplyTo":"b0943d9e0706221529w63a41e82r557179a45b461f61@mail.gmail.com","subject":"Re: [StGIT RFC] Changing patch@branch syntax","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-06-24T21:26:03Z","receivedAt":"2007-06-24T21:26:03Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Jun 22, 2007 at 11:29:14PM +0100, Catalin Marinas wrote:\n> On 22/06/07, Yann Dirson wrote:\n> >On Fri, Jun 22, 2007 at 04:59:05PM +0100, Catalin Marinas wrote:\n> >> I also don't think we need to make this distinction in the names as\n> >> different commands or options take different type of arguments:\n> >>\n> >> stg show \n> >> stg series --branch \n> >\n> >Currently, \"stg show HEAD\" or any other git ref does work, except when\n> >there are name clashes.\n> \n> But the argument to 'show' here is either a patch or a git ref (not a\n> stack or a pool). It first tries to find a patch and fall back to a\n> git ref. You don't specify a stack to 'show'.\n\nWell, currently \"stg show \" will just take as a git\nref, and will show the top commit, which may well be the base commit\nof the stack - not very exciting, I agree.\n\n\n> What might be easier with a complete spec is bash completion. I find\n> this mandatory precise description similar to the Hungarian notation.\n> Since most of the time I work with push/pop commands, I don't like\n> always putting a \":\" for every patch\n\nRight, push/pop should only get the local name in the current\npatchset, no \":\" whatsoever in there. It is not the same for \"show\",\nsince we often want to look at patches in other stacks.\n\n\n> (BTW, what about patch ranges, I don't think they can go across\n> multiple stacks).\n\nRight - we probably only want ranges in the rightmost component of a\npatchspec.\n\n\n> >And since we're going to have all of patches, stacks, and pools in the\n> >same \"stackable\" family, we're going to use them interchangeably in\n> >more and more places. But there are also places where we can use at\n> >will stack names and generic git heads (eg. \"stg branch X\").\n> \n> Currently, stack names and git branches are the same. Would this\n> change with hydra? I use StGIT to maintain my branches on\n> http://www.linux-arm.org/git?p=linux-2.6.git;a=heads and I find the\n> stack name == git branch simplification pretty useful.\n> \n> What commands/options would we have where we need to distinguish\n> between stack and patch names?\n\nI have often wondered if it would be useful to have a given\npatch@stack as a base for another stack, or maybe as one of the\n\"heads\" of an hydra. Still not sure it would make any sense, however\n- especially, proper use of hydras would possibly suppress the need\nfor the former.\n\n\n> >I'd rather having a single name-resolution mechanism, instead of one\n> >for patches and one for branches.\n> \n> I don't see why we couldn't have a single name resolution but without\n> the mandatory \":\". An example (but in reverse order) is internet\n> names. I only type \"intranet\" rather than \"intranet.\" in a browser. To\n> fully qualify, I type \"intranet.arm.com\".\n\nThere is a difference, in that in name resolution there is a\nwell-define algorithm to resolve this, and in that \"intranet\" alone is\nnot a valid fully-qualified name. In current StGIT, in cases where\n\"name\" matches both a local patch a git ref... well, we can still ask\nfor refs/heads/name as fully-qualified name - looks like I had\nforgotten that one ;)\n\n\nLet's try to find a proper solution.\n\nWe have on one hand a number of commands (in the patch/stack sets)\nthat act solely within the patchset, and thus have no need for\nreferencing stackables outside the current patchset:\n\n\tnew, push, pop, goto, float, sink, clean, uncommit, export,\n\timport, mail, refresh \n\nSimilar commands, but which no technical issue restrain from acting on\nstackables in other patchsets:\n\n\tdelete, hide, unhide, patches, series, files, log, rename, show\n\nCommands that solely refer to patchsets, not stackables:\n\n\tapplied, unapplied, top, branch, rebase\n\nCommands that need to refer to patches in other patchsets:\n\n\tpick\n\nCommands that don't care:\n\n\tassimilate, commit, init, pull, fold\n\n\nI consider we have a couple of special cases:\n\n\tclean currently does not care, but see task #5235\n\trebase currently only needs patchets, do we need to extend that to patches ?\n\tmail currently does not accept --branch or patch@stack but probably could\n\tnew creates a patch in the current stack, we may want to unify\n\t\tthis with \"branch -c\" in some way (maybe \"stg\n\t\t(patch|stack|pool) new\" ?)\n\tshow is special in that when its arg is not a ref to a patch,\n\t\tit falls back to git-show. We may want to change\n\t\tthat, to be an stgit-only command.\n\tsync uses non-standard way to refer to the other stack - do we\n\t\treally need to sync several patches in one command ?\n\n\tclone is also special, in that it is currently the only one to\n\t\thave a use for the repo - it could surely be extended\n\t\tto accept a stackable (eg. \"stg clone http://this/repo#pool2:stk1\")\n\nTo summarize, appart from \"show\" which does not really need to know\nabout branches, no current command would have any ambiguity.\n\nA couple of commands in the 1st category will needto be enhanced to be\nmore useful with pools of stacks (to specify which stack of the pool\nto act on), but that does not change the problem, they do not act on\nnon-stackable git-core branches.\n\n\n> If it is easier for you, you could create a branch (for-upstream etc.)\n> and just send me an email to merge it.\n\nRight. With a bit more work on hydra/pool, I could even tell you to\npull from an pool member ;)\n\n\n> - concreteCommand, I would write classes with capital first letter\n> (unwritten convention in StGIT)\n\nOK\n\n\n> - why the Repository class definition in stgit/__init__.py? Can it not\n> be in a different file?\n\nThis is part of the things to clean up. By putting it here I was sure\nthe class was going to available as stgit.Repository. I'm not fluent\nin python yet, I'll have to dig for a better way - that one surely\ndoes not scale at all.\n\n\n> Also, shourt stgit/git.py be aware of the repository?\n\nI'd rather think that we should have git.Repository (and further\nstructurate git.py with more objects, like git.Branch), with\nstgit-specific stuff in the stgit.Repository subclass.\n\nBest regards,\n-- \nYann.\n"},{"id":"45805","messageId":"b0943d9e0706251522s6baf7997r48beae7f57681d77@mail.gmail.com","threadId":"8171","inReplyTo":"20070624212603.GA6361@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [StGIT RFC] Changing patch@branch syntax","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-06-25T22:22:15Z","receivedAt":"2007-06-25T22:22:15Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 24/06/07, Yann Dirson wrote:\n> Well, currently \"stg show \" will just take as a git\n> ref, and will show the top commit, which may well be the base commit\n> of the stack - not very exciting, I agree.\n\nIndeed. The 'show' command was meant for patches but I added the\nsupport to fall back to git commits.\n\n> > What might be easier with a complete spec is bash completion. I find\n> > this mandatory precise description similar to the Hungarian notation.\n> > Since most of the time I work with push/pop commands, I don't like\n> > always putting a \":\" for every patch\n>\n> Right, push/pop should only get the local name in the current\n> patchset, no \":\" whatsoever in there. It is not the same for \"show\",\n> since we often want to look at patches in other stacks.\n\nYes, but most of the time I look at patches on the current branch.\n\n> I have often wondered if it would be useful to have a given\n> patch@stack as a base for another stack, or maybe as one of the\n> \"heads\" of an hydra. Still not sure it would make any sense, however\n> - especially, proper use of hydras would possibly suppress the need\n> for the former.\n\nThere are situations when I want a separate branch but it relies on\npatches in other branches. I currently duplicate the patches and use\nthe 'sync' command to keep them up to date (though this command would\nbe more useful with support for git-rerere to avoid fixing the same\nconflict several times).\n\nCan a patch series be part of multiple pools? This would be useful to\nmy workflow.\n\n> > >I'd rather having a single name-resolution mechanism, instead of one\n> > >for patches and one for branches.\n> >\n> > I don't see why we couldn't have a single name resolution but without\n> > the mandatory \":\". An example (but in reverse order) is internet\n> > names. I only type \"intranet\" rather than \"intranet.\" in a browser. To\n> > fully qualify, I type \"intranet.arm.com\".\n>\n> There is a difference, in that in name resolution there is a\n> well-define algorithm to resolve this, and in that \"intranet\" alone is\n> not a valid fully-qualified name.\n\nNo, it's not fully qualified but it gets the .arm.com by default. If\nit fails, the browser will complain.\n\n> In current StGIT, in cases where\n> \"name\" matches both a local patch a git ref... well, we can still ask\n> for refs/heads/name as fully-qualified name - looks like I had\n> forgotten that one ;)\n\nStGIT could default to patches and fall back to git commits if no \":\"\nare found in the name.\n\n> Let's try to find a proper solution.\n>\n> We have on one hand a number of commands (in the patch/stack sets)\n> that act solely within the patchset, and thus have no need for\n> referencing stackables outside the current patchset:\n>\n> new, push, pop, goto, float, sink, clean, uncommit, export,\n> import, mail, refresh\n>\n> Similar commands, but which no technical issue restrain from acting on\n> stackables in other patchsets:\n>\n> delete, hide, unhide, patches, series, files, log, rename, show\n>\n> Commands that solely refer to patchsets, not stackables:\n>\n> applied, unapplied, top, branch, rebase\n\nThose that can refer to other patchsets have the '--branch' argument,\notherwise they just use the current series.\n\n> Commands that need to refer to patches in other patchsets:\n>\n> pick\n>\n> Commands that don't care:\n>\n> assimilate, commit, init, pull, fold\n>\n>\n> I consider we have a couple of special cases:\n>\n> clean currently does not care, but see task #5235\n> rebase currently only needs patchets, do we need to extend that to patches ?\n\n'rebase' could only work on the current patchset because of the\npossibility of getting conflicts during push (unless you implement the\nbranch switching as well).\n\n> mail currently does not accept --branch or patch@stack but probably could\n\nYes.\n\n> new creates a patch in the current stack, we may want to unify\n> this with \"branch -c\" in some way (maybe \"stg\n> (patch|stack|pool) new\" ?)\n\nThis might be a possibility once we refactor the command line.\n\n> show is special in that when its arg is not a ref to a patch,\n> it falls back to git-show. We may want to change\n> that, to be an stgit-only command.\n\nWe need the commit id generation for the 'pick' command and 'show'\nwould use the same code. I don't think we should restrict it.\n\n> sync uses non-standard way to refer to the other stack - do we\n> really need to sync several patches in one command ?\n\nI have stacks with more than 10 common patches and it is useful to\nupdate them with only one command (I do this many times only as a\nsimple check).\n\n> clone is also special, in that it is currently the only one to\n> have a use for the repo - it could surely be extended\n> to accept a stackable (eg. \"stg clone http://this/repo#pool2:stk1\")\n\nYes, it would be nice.\n\n> To summarize, appart from \"show\" which does not really need to know\n> about branches, no current command would have any ambiguity.\n\nIf we don't want ambiguities in the UI, we could restrict 'show' only\nto the StGIT patches (though I personally don't mind the fall-back to\nGIT objects).\n\n> > Also, shourt stgit/git.py be aware of the repository?\n>\n> I'd rather think that we should have git.Repository (and further\n> structurate git.py with more objects, like git.Branch), with\n> stgit-specific stuff in the stgit.Repository subclass.\n\nSounds good.\n\nThanks.\n\n-- \nCatalin\n"},{"id":"45854","messageId":"20070626223143.GG7730@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8171","inReplyTo":"b0943d9e0706251522s6baf7997r48beae7f57681d77@mail.gmail.com","subject":"Re: [StGIT RFC] Changing patch@branch syntax","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-06-26T22:31:43Z","receivedAt":"2007-06-26T22:31:43Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, Jun 25, 2007 at 11:22:15PM +0100, Catalin Marinas wrote:\n> >I have often wondered if it would be useful to have a given\n> >patch@stack as a base for another stack, or maybe as one of the\n> >\"heads\" of an hydra. Still not sure it would make any sense, however\n> >- especially, proper use of hydras would possibly suppress the need\n> >for the former.\n> \n> There are situations when I want a separate branch but it relies on\n> patches in other branches. I currently duplicate the patches and use\n> the 'sync' command to keep them up to date (though this command would\n> be more useful with support for git-rerere to avoid fixing the same\n> conflict several times).\n> \n> Can a patch series be part of multiple pools? This would be useful to\n> my workflow.\n\nIn the current prototype, yes, since the current \"hydra\" object only\nbinds existing stacks. In the design we've discussed, not directly -\nlet's find a solution.\n\nMy idea of what we've discussed most recently is that stackables will\nbe *contained* in patchsets. Ie. a pool will be able to contain both\npatches-as-we-know-them, and stacks, but those stacks won't be git\nheads, only refs in a namespace still to be decided upon - something\nsimilar to how we currently store patch refs.\n\nTo allow sharing a stack between several pools, I can see 2 options.\nThe easiest to implement (but not necessarily the easiest to live\nwith) is to clone and sync the stack.\n\nAnother one is to add another Stackable subclass (eg. StackableLink),\nthat would figure some sort of symbolic link to the reference\nStackable. It would provide in the current patchset a local name for\nthe linked Stackable, but may need to be more than a simple alias: a\npool is, at least for now, an octopus, and thus only supports\nconflict-less members; thus, if the linked Stackable changes to be\nincompatible with the link siblings, the patchset containing the\nconflict would instantly become invalid. Either we add support for\nthis \"invalidated\" status, or we find a better way. One possibility I\nthought of, is that the link will point a specific version of its\nreferenced stackable (a point always reachable from new versions of\nthe referenced stackable through its patch/ref/stack/whatever-log),\nand the user will need to explicitely stg-pull to get the new version,\nwith the option to \"pull --undo\" if he does not like it.\n\nAll these options leave room for innovative workflows :)\n\n\n> >In current StGIT, in cases where\n> >\"name\" matches both a local patch a git ref... well, we can still ask\n> >for refs/heads/name as fully-qualified name - looks like I had\n> >forgotten that one ;)\n> \n> StGIT could default to patches and fall back to git commits if no \":\"\n> are found in the name.\n\nI'd rather leave this fallback to the minimum (esp. if only \"show\" and\n\"pick\" can make sense out of it).\n\n\n> >I consider we have a couple of special cases:\n> >\n> > clean currently does not care, but see task #5235\n> > rebase currently only needs patchets, do we need to extend that to \n> > patches ?\n> \n> 'rebase' could only work on the current patchset because of the\n> possibility of getting conflicts during push (unless you implement the\n> branch switching as well).\n\nThat's not what I was thinking about. I was mentionning the\npossibility to rebase to a given patch, so \"pull\" will follow later\nversions of that patch. Not sure it is useful, though, and it can\nprobably already be done by rebasing to refs/patches//\n(although that accesses implementation details, that rebasing to\n: would not need to).\n\n\n> > new creates a patch in the current stack, we may want to unify\n> > this with \"branch -c\" in some way (maybe \"stg\n> > (patch|stack|pool) new\" ?)\n> \n> This might be a possibility once we refactor the command line.\n\nRight - that was subliminally suggesting to refactor the command-line\nbefore 1.0, in fact ;)\n\n\n> >> Also, shourt stgit/git.py be aware of the repository?\n> >\n> >I'd rather think that we should have git.Repository (and further\n> >structurate git.py with more objects, like git.Branch), with\n> >stgit-specific stuff in the stgit.Repository subclass.\n> \n> Sounds good.\n\nCool.\n\nBest regards,\n-- \nYann\n"},{"id":"46663","messageId":"20070706220406.GR7730@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8171","inReplyTo":"20070626223143.GG7730@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [StGIT RFC] Changing patch@branch syntaxtackable> ::= | :","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-07-06T22:04:06Z","receivedAt":"2007-07-06T22:04:06Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"\nMy thoughts about stg-show suggested me we can extend on the latest\nproposed syntax, by allowing comma-separated sequences of patch\nranges. Such ranges would not be limitted to patches either, they\nwould be meaningful within any patchset (or maybe within ordered\npatchsets only, should we feel this restriction necessary). Eg:\n\n\tstg show ::foo,bar..buz\n\nPatch attributes OTOH probably don't play well with ranges - which I\ntake as a symptom that we should be careful about them.\n\nWe may also want to generalize the patch//attribute mechanism a bit\nmore, eg. so \"base\" is not seen as a fake patch, but rather an\nattribute of the patchset. That is, something like\n\"://base\" should be a valid id.\n\nLet's try to get a full formal syntax, based on the one you formerly\nproposed.\n\n ::= [^\\w.-]+\n ::= 'top' | 'top.old' | 'bottom' | 'bottom.old' | 'log' | ...\n ||| ::= \n ::= | | \n\n ::= ? | ':' ?\n := ':' \n\n ::= ( | ) ? '//' \n\n ::= | '..' ? | '..' \n ::= | ',' \n\n := ':' \n\n\nOn Wed, Jun 27, 2007 at 12:31:43AM +0200, Yann Dirson wrote:\n> On Mon, Jun 25, 2007 at 11:22:15PM +0100, Catalin Marinas wrote:\n> > Can a patch series be part of multiple pools? This would be useful to\n> > my workflow.\n>\n> In the current prototype, yes, since the current \"hydra\" object only\n> binds existing stacks. In the design we've discussed, not directly -\n> let's find a solution.\n>\n> My idea of what we've discussed most recently is that stackables will\n> be *contained* in patchsets. Ie. a pool will be able to contain both\n> patches-as-we-know-them, and stacks, but those stacks won't be git\n> heads, only refs in a namespace still to be decided upon - something\n> similar to how we currently store patch refs.\n>\n> To allow sharing a stack between several pools, I can see 2 options.\n> The easiest to implement (but not necessarily the easiest to live\n> with) is to clone and sync the stack.\n\nGiven the complexity of the approaches I proposed, we may want to keep\nan \"hydra\" type besides \"pools\". After all, we may implement as many\nPatchSet subclasses we can think of :)\n\nBest regards,\n-- \nYann\n"}]}