{"thread":{"id":"43157","subject":"Re: Handling of branches in stgit","startedAt":"2006-11-30T00:00:38Z","lastAt":"2006-12-05T22:51:37Z","messageCount":4,"participants":["Catalin Marinas","Yann Dirson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298373","messageId":"20061130000038.GA13324@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"43157","inReplyTo":null,"subject":"Handling of branches in stgit","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-11-30T00:00:38Z","receivedAt":"2006-11-30T00:00:38Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"I have started to work on recording parent information for stgit\nbranches, so we don't need to give the same info on every \"git pull\".\n\nI'm facing a problem, in that we have several kind of stgit branches:\n\n* those created against a cogito branch (eg. by \"cg clone\" and \"stg\n init\"). They work pretty much intuitively (and it happens I mostly\n used this flavour before those tests). All we need is the name of\n the local branch, and \"stg pull \" relies on \"git fetch\" to\n find the repository information in .git/branches/.\n\n In this case, it is easy to request pulling from any branch, but\n usually only one of them is what you want, and the results of using\n another one (or forgetting to specify the one you want) can be\n annoying [ISSUE 1]. Hence this work of mine: being able to store\n this info in .git/patches//parent (my initial implementation)\n was sufficient in theory.\n\n But \"stg pull\" allows for a refspec argument. Since the branch\n mapping is already defined in a file, and I canno think of any\n useful way to override it, maybe we could make sure noone uses it in\n such a case ?\n\n \n* but those created against a local branch are typically different,\n and updated by \"stg pull . \". In that case, we have to\n specify the repository (\".\") explicitely, in addition to the branch,\n and the way to use the use them is different.\n\n\n* and it gets better with those branches created against a git remote\n branch (eg. by \"stg clone\" or \"stg branch -c\" against an existing\n remote branch), typically updated via \"stg pull \", where the\n repo information is extracted by \"git fetch\" from\n .git/remotes/. That is, we do not specify a branch or a\n repository URL, but an alias that may cover several branches from\n another repo.\n\n Here the branch information from the remotes file appears not to be\n used at all (in fact all branches are fetched - not sure that it's\n always what we want, but I'll wait to find myself limited by this\n behaviour before complaining ;)\n\n Also, \"stgit pull \" using \"git pull\" by default, it is the\n 1st branch listed in the remotes file that gets taken as parent\n [ISSUE 2]. We should probably instead run \"git fetch \" and\n then then \"git pull . \", but that surely requires some\n changes to the \"stg pull\" internals.\n\n Thus (modulo that issue), we need 2 infos: \"remote\" and branch.\n Storing the latter should help to solve issue 2.\n\n Note: whereas \"stg pull origin\", while pulling a \"foo\" branch, cannot\n know current \"foo2\" branch should be rebased to \"foo\", (after renaming\n remotes/origin to foo) \"stg pull foo\", not only fetches \"origin\" as\n expected, but also (seemingly correctly but hell how does it know\n [ISSUE 3]) rebases current \"master\" to \"origin\" - is \"master\"\n special in any way here ? I did not find anything about this in the\n source, although I found a handful of occurences of \"master\" in\n commands/branch.py, which seem to imply \"master\" is so special it\n cannot be deleted, which would look like abuse to me [ISSUE 4].\n\n\nNow what do we do next ?\n\nWe could implement an ad-hoc solution acknowledging there are 3\ndifferent ways to work with a branch, keeping the current \"stg pull\"\nsyntaxes (they are already a pain for users IMHO) and storing\nparemeters as ad-hoc values, or we could try to rework the \"stg pull\"\ncommand line.\n\nSome of my ideas for the latter include:\n\n- store a \"parent branch\" with the name of the parent branch in the\nlocal repository\n\n- store a \"parent repository\" (ie. \".\" for local branches, \"AUTO\" for\ncogito branches, and for git branches)\n\n- rejecting non-default arguments and adding new options to allow to\nspecify/store alternative values\n\n- we'll need to make sure there are no remote branches of one type\nshadowed by one of the other type with same name, and do some sanity\nchecks that specified branch in a given remote really exists.\n\n\nHow does that sound ?\n-- \n"},{"id":"293944","messageId":"b0943d9e0612010442gf7bf2ccr8995967403788fe7@mail.gmail.com","threadId":"43157","inReplyTo":"20061130000038.GA13324@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Handling of branches in stgit","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-12-01T12:42:19Z","receivedAt":"2006-12-01T12:42:19Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 30/11/06, Yann Dirson wrote:\n> I have started to work on recording parent information for stgit\n> branches, so we don't need to give the same info on every \"git pull\".\n\nIsn't this what the branch..remote configuration option is for?\nI think we should leave GIT handle this and StGIT only invoke \"git\npull\" without any arguments.\n\n> I'm facing a problem, in that we have several kind of stgit branches:\n>\n> * those created against a cogito branch (eg. by \"cg clone\" and \"stg\n> init\"). They work pretty much intuitively (and it happens I mostly\n> used this flavour before those tests). All we need is the name of\n> the local branch, and \"stg pull \" relies on \"git fetch\" to\n> find the repository information in .git/branches/.\n\nBut I think .git/branches got deprecated or it is a cogito-only feature.\n\n> In this case, it is easy to request pulling from any branch, but\n> usually only one of them is what you want, and the results of using\n> another one (or forgetting to specify the one you want) can be\n> annoying [ISSUE 1]. Hence this work of mine: being able to store\n> this info in .git/patches//parent (my initial implementation)\n> was sufficient in theory.\n\nI would leave this to GIT and its configuration files. Do you see any\nproblems with this approach?\n\nI plan to merge the stgit config with the git one (and have a [stgit]\nsection) so that it is more maintainable.\n\n-- \n"},{"id":"298187","messageId":"20061201221941.GA32337@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"43157","inReplyTo":"b0943d9e0612010442gf7bf2ccr8995967403788fe7@mail.gmail.com","subject":"Re: Handling of branches in stgit","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-12-01T22:19:41Z","receivedAt":"2006-12-01T22:19:41Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Dec 01, 2006 at 12:42:19PM +0000, Catalin Marinas wrote:\n> On 30/11/06, Yann Dirson wrote:\n> >I have started to work on recording parent information for stgit\n> >branches, so we don't need to give the same info on every \"git pull\".\n> \n> Isn't this what the branch..remote configuration option is for?\n> I think we should leave GIT handle this and StGIT only invoke \"git\n> pull\" without any arguments.\n\nThis is one part of the problem (and I admit I have missed this config option),\nthe other one being having stgit pull the correct branch, unstead of\n(implicitely) having git-pull using the 1st one in the remotes file.\n\n\n> >I'm facing a problem, in that we have several kind of stgit branches:\n> >\n> >* those created against a cogito branch (eg. by \"cg clone\" and \"stg\n> > init\"). They work pretty much intuitively (and it happens I mostly\n> > used this flavour before those tests). All we need is the name of\n> > the local branch, and \"stg pull \" relies on \"git fetch\" to\n> > find the repository information in .git/branches/.\n> \n> But I think .git/branches got deprecated or it is a cogito-only feature.\n\n.git/branches still seems to be the only type of branch created by\ncogito. And in fact, when remotes started to appear, I wondered how the \ncogito branch management (a quite intuitive and classical one) would be\nmade to work well with remotes-defining-several-branches, as well as\nbranches-potentially-defined-in-several-remotes (possible repo\ninconsistency AFAICT, or maybe to specify different protocols to a\nsingle repo ?) - and indeed I still don't have an answer, I guess cogito\nwould have to possibly change its user interface if it were to be able\nto use multi-branch remotes.\n\nIn the meantime, we should support them in cogito. And indeed, I found\nstgit to work perfectly with those.\n\n\n> > In this case, it is easy to request pulling from any branch, but\n> > usually only one of them is what you want, and the results of using\n> > another one (or forgetting to specify the one you want) can be\n> > annoying [ISSUE 1]. Hence this work of mine: being able to store\n> > this info in .git/patches//parent (my initial implementation)\n> > was sufficient in theory.\n> \n> I would leave this to GIT and its configuration files. Do you see any\n> problems with this approach?\n\nI'd rather consider it a stgit issue: git itself does no have to know\nwhich of the various heads descending from our stack base is to be\n\"prefered\" by our stack. Where to store it is anothe issue (see below).\n\n\n> I plan to merge the stgit config with the git one (and have a [stgit]\n> section) so that it is more maintainable.\n\nSure, let's take advantage of git-repo-config !\nMy latest 1/3 patch could then be seen as a 1st step towards an\nabstraction of stgit object configuration, which could ease the transition\nfrom file storage to config items :)\n\nBest regards,\n-- \nYann.\n"},{"id":"297085","messageId":"20061205225137.GA17132@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"43157","inReplyTo":"20061201221941.GA32337@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Handling of branches in stgit","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-12-05T22:51:37Z","receivedAt":"2006-12-05T22:51:37Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Dec 01, 2006 at 11:19:41PM +0100, Yann Dirson wrote:\n> > > annoying [ISSUE 1]. Hence this work of mine: being able to store\n> > > this info in .git/patches//parent (my initial implementation)\n> > > was sufficient in theory.\n> > \n> > I would leave this to GIT and its configuration files. Do you see any\n> > problems with this approach?\n> \n> I'd rather consider it a stgit issue: git itself does no have to know\n> which of the various heads descending from our stack base is to be\n> \"prefered\" by our stack. Where to store it is anothe issue (see below).\n> \n> \n> > I plan to merge the stgit config with the git one (and have a [stgit]\n> > section) so that it is more maintainable.\n> \n> Sure, let's take advantage of git-repo-config !\n> My latest 1/3 patch could then be seen as a 1st step towards an\n> abstraction of stgit object configuration, which could ease the transition\n\nIndeed most of the current attributes of a stack (except maybe for the\ndescription, which can hardly be seen as a config option) are quite\nvolatile, and thus unsuited for repo-config.\nOTOH, as you said parent information would find easily its place there.\n\n\n> > On 30/11/06, Yann Dirson wrote:\n> > >I have started to work on recording parent information for stgit\n> > >branches, so we don't need to give the same info on every \"git pull\".\n> >\n> > Isn't this what the branch..remote configuration option is for?\n> > I think we should leave GIT handle this and StGIT only invoke \"git\n> > pull\" without any arguments.\n> \n> This is one part of the problem (and I admit I have missed this config option),\n> the other one being having stgit pull the correct branch, unstead of\n> (implicitely) having git-pull using the 1st one in the remotes file.\n\nI would also think that what really belongs to that config item would\nbe the declaration of which remote our parent branch should use to be\nupdated (ie. no need to duplicate the info in all the stgit stacks\nforked off the same parent).\n\nHowever it looks like this config option is not currently used unless\nthe branch to be git-fetched is the curent one, which is quite\nannoying - we would need to get that setting ourselves to pass it to\ngit-fetch.\n\nWhat's not clear to me is how to deal with cogito branches (maybe\ncheck for the existence of .git/branches/ and then \"git fetch\n\" ?), and with local branches (how are we supposed to derive\nthat a branch is not a remote one ? Should GIT add a\nbranch..remote or \".\" for locally-created branches ?).\n\n\nWe would also still need a config item to tell which parent branch we\nshould use, in order to know which branch..remote to extract,\nand which branch to fast-forward our base onto.\n\nBest regards,\n-- \n"}]}