{"thread":{"id":"6319","subject":"Howto use StGit and git-svn at same time","startedAt":"2007-01-09T21:35:21Z","lastAt":"2007-01-28T23:21:19Z","messageCount":36,"participants":["Guilhem Bonnefille","Yann Dirson","Catalin Marinas","Jakub Narebski","Karl Hasselström","David Kågedal","Theodore Tso"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"31288","messageId":"8b65902a0701091335u160c6dfl81a523e4cd5adbee@mail.gmail.com","threadId":"6319","inReplyTo":null,"subject":"Howto use StGit and git-svn at same time","fromName":"Guilhem Bonnefille","fromEmail":"guilhem.bonnefille@gmail.com","sentAt":"2007-01-09T21:35:21Z","receivedAt":"2007-01-09T21:35:21Z","isPatch":false,"sender":{"key":"guilhem.bonnefille@gmail.com","avatar":"https://gravatar.com/avatar/375364bfee1f61197c540e37465abe3619fc24eb3a36b0edcea7f15b124036b0?d=mp&s=160"},"body":"Hi,\n\nI'm a newbie and I'm using:\n- git-svn to connect to a public SVN repo,\n- StGit to manage my patches for the project hosted by this repo.\n\nThe current GIT repo was previously cloned from a GIT repo made with\ngit-cvsimport. But the project moved to SVN, so I removed the GIT repo\nconnected to the CVS.\n\nI succesfully fetch the SVN, create a \"work\" local branch (connected\nto remotes/trunk), and create some patches.\nAs the SVN evolved, I wish to retrieve info and update my patches.\n\nSo I tried a \"stg pull\" whihc failed because \"origin\" no more exists.\nSo, I tried a \"git-rebase remotes/trunk\".\nIs it correct?\n\nI'm actually unable to conclude, as the maintainer apply my patches\nwith some improves, so I have to solve lots of conflicts. But I would\nappreciate if you can confirm me that the git-rebase is the good way\nto update a \"workspace\" managed both by git-svn and StGit.\n\n-- \nGuilhem BONNEFILLE\n-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n-=- mailto:guilhem.bonnefille@gmail.com\n-=- http://nathguil.free.fr/\n"},{"id":"31290","messageId":"8b65902a0701091341v5983c113tc5cd32c6c4c57719@mail.gmail.com","threadId":"6319","inReplyTo":"8b65902a0701091335u160c6dfl81a523e4cd5adbee@mail.gmail.com","subject":"Re: Howto use StGit and git-svn at same time","fromName":"Guilhem Bonnefille","fromEmail":"guilhem.bonnefille@gmail.com","sentAt":"2007-01-09T21:41:20Z","receivedAt":"2007-01-09T21:41:20Z","isPatch":false,"sender":{"key":"guilhem.bonnefille@gmail.com","avatar":"https://gravatar.com/avatar/375364bfee1f61197c540e37465abe3619fc24eb3a36b0edcea7f15b124036b0?d=mp&s=160"},"body":"Humh...\nI finished the conflicts solving game. I think the way I choosed is\nincorrect. Following gitk, it is now a big big bazaar in my commits\nhistory.\n\nCan you give me some tips about using both git-svn and stgit please?\n\nOn 1/9/07, Guilhem Bonnefille wrote:\n> Hi,\n>\n> I'm a newbie and I'm using:\n> - git-svn to connect to a public SVN repo,\n> - StGit to manage my patches for the project hosted by this repo.\n>\n> The current GIT repo was previously cloned from a GIT repo made with\n> git-cvsimport. But the project moved to SVN, so I removed the GIT repo\n> connected to the CVS.\n>\n> I succesfully fetch the SVN, create a \"work\" local branch (connected\n> to remotes/trunk), and create some patches.\n> As the SVN evolved, I wish to retrieve info and update my patches.\n>\n> So I tried a \"stg pull\" whihc failed because \"origin\" no more exists.\n> So, I tried a \"git-rebase remotes/trunk\".\n> Is it correct?\n>\n> I'm actually unable to conclude, as the maintainer apply my patches\n> with some improves, so I have to solve lots of conflicts. But I would\n> appreciate if you can confirm me that the git-rebase is the good way\n> to update a \"workspace\" managed both by git-svn and StGit.\n>\n> --\n> Guilhem BONNEFILLE\n> -=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n> -=- mailto:guilhem.bonnefille@gmail.com\n> -=- http://nathguil.free.fr/\n>\n\n\n-- \nGuilhem BONNEFILLE\n-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n-=- mailto:guilhem.bonnefille@gmail.com\n-=- http://nathguil.free.fr/\n"},{"id":"31299","messageId":"20070109224125.GF17093@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"8b65902a0701091341v5983c113tc5cd32c6c4c57719@mail.gmail.com","subject":"Re: Howto use StGit and git-svn at same time","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-09T22:41:25Z","receivedAt":"2007-01-09T22:41:25Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Tue, Jan 09, 2007 at 10:41:20PM +0100, Guilhem Bonnefille wrote:\n> Humh...\n> I finished the conflicts solving game. I think the way I choosed is\n> incorrect. Following gitk, it is now a big big bazaar in my commits\n> history.\n\nRight, you should not use git-rebase on a StGIT branch :)\n\nWhat you should have done is moving your stack base from your old\norigin branch to remotes/trunk - something that StGIT does not support\nyet from command-line, but I've done this manually in the past\n(migrating an StGIT stack after re-running a full git-cvsimport after\nthe original cvs branch got corrupted).\n\nSomething along the line of (untested, off the top of my head):\n\n$ stg pop -a\n$ echo > .git/refs/heads/\n$ echo > .git/refs/bases/\n\nAnd then use \"stg push\" and \"stg resolved -i\" to resolve the conflicts.\n\nBut always be sure of backing up your .git before doing such by-hand\nexperiments.\n\nBest regards,\n-- \nYann.\n"},{"id":"31743","messageId":"8b65902a0701150526j5a954529xf45b2d0348a77573@mail.gmail.com","threadId":"6319","inReplyTo":"20070109224125.GF17093@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Howto use StGit and git-svn at same time","fromName":"Guilhem Bonnefille","fromEmail":"guilhem.bonnefille@gmail.com","sentAt":"2007-01-15T13:26:36Z","receivedAt":"2007-01-15T13:26:36Z","isPatch":false,"sender":{"key":"guilhem.bonnefille@gmail.com","avatar":"https://gravatar.com/avatar/375364bfee1f61197c540e37465abe3619fc24eb3a36b0edcea7f15b124036b0?d=mp&s=160"},"body":"Ok, thanks for the reminder: I forgot \"stg pop/push\".\n\nI redo whole job as this:\n- git-svn -i trunk fetch\n- stg pop -a\n- git-rebase remotes/trunk # as recommended by git-svn manual\n- stg push -a\n- playing another merging game as my patches submissions were modified\nsince archived\n\nThanks.\n\nOn 1/9/07, Yann Dirson wrote:\n> On Tue, Jan 09, 2007 at 10:41:20PM +0100, Guilhem Bonnefille wrote:\n> > Humh...\n> > I finished the conflicts solving game. I think the way I choosed is\n> > incorrect. Following gitk, it is now a big big bazaar in my commits\n> > history.\n>\n> Right, you should not use git-rebase on a StGIT branch :)\n>\n> What you should have done is moving your stack base from your old\n> origin branch to remotes/trunk - something that StGIT does not support\n> yet from command-line, but I've done this manually in the past\n> (migrating an StGIT stack after re-running a full git-cvsimport after\n> the original cvs branch got corrupted).\n>\n> Something along the line of (untested, off the top of my head):\n>\n> $ stg pop -a\n> $ echo > .git/refs/heads/\n> $ echo > .git/refs/bases/\n>\n> And then use \"stg push\" and \"stg resolved -i\" to resolve the conflicts.\n>\n> But always be sure of backing up your .git before doing such by-hand\n> experiments.\n>\n> Best regards,\n> --\n> Yann.\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\n-- \nGuilhem BONNEFILLE\n-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n-=- mailto:guilhem.bonnefille@gmail.com\n-=- http://nathguil.free.fr/\n"},{"id":"31762","messageId":"20070115202412.GE9761@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"8b65902a0701150526j5a954529xf45b2d0348a77573@mail.gmail.com","subject":"Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-15T20:24:12Z","receivedAt":"2007-01-15T20:24:12Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, Jan 15, 2007 at 02:26:36PM +0100, Guilhem Bonnefille wrote:\n> >What you should have done is moving your stack base from your old\n> >origin branch to remotes/trunk - something that StGIT does not support\n> >yet from command-line, but I've done this manually in the past\n> >(migrating an StGIT stack after re-running a full git-cvsimport after\n> >the original cvs branch got corrupted).\n\nI have started work on implementing \"stg pull --to \", but I'm\nfacing some issues.\n\n \"stg pull\", after popping all patches, currently calls \"git pull\",\n which indeed has 2 roles:\n\n- running \"git fetch\" on the parent branch\n- updating the head of the stack (which matches the base since\n no patch is applied), by relying on git-pull to fast-forward the\n stack head\n\nThe latter is, unless I miss something:\n\n- overkill when what we want is just to move the head to another place\n\n- problematic when the parent branch is one that would be tracker with\n\"+\" in the remote pull line (eg. \"next\", \"pu\", or an stgit stack). In\nthat case, although \"git fetch\" refuses to update the parent head\nbecause it would not be a fast-forward, git-pull then attempt to do a\nmerge, which completely breaks expectations.\n\nWhat my implementation of \"pull --to\" does is just moving the head\nwith the following code added to git.py:\n\ndef move_branch(tree_id):\n \"\"\"Move HEAD to another commit\n \"\"\"\n __set_head(tree_id)\n switch(tree_id)\n\n if os.path.isfile(os.path.join(basedir.get(), 'MERGE_HEAD')):\n os.remove(os.path.join(basedir.get(), 'MERGE_HEAD'))\n\n\nThat only partly works - that is, it works if I add the expected \"+\"\nin the remote refspec line (or if I add an explicit refspec on\ncommand-line). There is surely a way for \"stg clone\" to detect the\nparent is an stgit stack, and we can possibly have the clone operation\nsetup things right from the start. I remember someone suggesting that\nsuch branches advertise their status so git-clone itself would add\nthis - not sure this is planned for 1.5.0, though.\n\nEven when this fully works, I'm reluctant to leave things that way,\nbecause would be easy to forget the --to, and get a broken stack, with\n\"stg diff\" being confused enough to happily show this:\n\n|bar$ stg diff; echo $?\n|* Unmerged path file\n|0\n\n\nI would be of the opinion to stop calling \"git pull\" entirely, and use\n\"git fetch and the git.move_branch show above. Unless I hear about\nbetter ideas, my next patch set will be along those lines.\n\nBest regards,\n-- \nYann.\n"},{"id":"31781","messageId":"b0943d9e0701151446l45eff9dbgcae718c1461d0725@mail.gmail.com","threadId":"6319","inReplyTo":"20070115202412.GE9761@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Rebasing stgit stacks","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-01-15T22:46:37Z","receivedAt":"2007-01-15T22:46:37Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 15/01/07, Yann Dirson wrote:\n> On Mon, Jan 15, 2007 at 02:26:36PM +0100, Guilhem Bonnefille wrote:\n> > >What you should have done is moving your stack base from your old\n> > >origin branch to remotes/trunk - something that StGIT does not support\n> > >yet from command-line, but I've done this manually in the past\n> > >(migrating an StGIT stack after re-running a full git-cvsimport after\n> > >the original cvs branch got corrupted).\n>\n> I have started work on implementing \"stg pull --to \", but I'm\n> facing some issues.\n\nI think the combination of 'pull' and '--to' is confusing (at least to\nme) if you think of there English meaning.\n\n> \"stg pull\", after popping all patches, currently calls \"git pull\",\n> which indeed has 2 roles:\n>\n> - running \"git fetch\" on the parent branch\n> - updating the head of the stack (which matches the base since\n> no patch is applied), by relying on git-pull to fast-forward the\n> stack head\n\nAs Petr suggested at the OLS last year, I added the possibility to\nconfigure the 'git pull' command so that people use whatever script\nthey like.\n\n> The latter is, unless I miss something:\n>\n> - overkill when what we want is just to move the head to another place\n\nDoesn't git automatically detect that it can do a fast forward? A\nfetch is still necessary anyway.\n\nI'm not sure how people intend to use StGIT. Some might have their own\nchanges to the base of the stack (maybe caused by 'stg commit') and\nwould want 'git pull' to do a proper merge and not just fast-forward.\n\nI actually did the above when maintaining a public (well, ARM internal\nonly currently) kernel branch for other people to pull from. Since\nStGIT is not public branch friendly, I was working on a set of patches\n(mainly picking from other branches and minor modifications) and just\ncommitting them when finishing. Further updates from kernel.org\ntriggered full merges with the base.\n\n> - problematic when the parent branch is one that would be tracker with\n> \"+\" in the remote pull line (eg. \"next\", \"pu\", or an stgit stack). In\n> that case, although \"git fetch\" refuses to update the parent head\n> because it would not be a fast-forward, git-pull then attempt to do a\n> merge, which completely breaks expectations.\n\nIs there any way to configure git (via gitconfig) to behave\ndifferently? You can add some per-branch options with the parent to\npull from but this would require separate .git/remotes/ files for each\nbranch.\n\n> What my implementation of \"pull --to\" does is just moving the head\n> with the following code added to git.py:\n>\n> def move_branch(tree_id):\n> \"\"\"Move HEAD to another commit\n> \"\"\"\n> __set_head(tree_id)\n> switch(tree_id)\n\nThe switch() function already calls __set_head()\n\n> if os.path.isfile(os.path.join(basedir.get(), 'MERGE_HEAD')):\n> os.remove(os.path.join(basedir.get(), 'MERGE_HEAD'))\n\nWhen is the MERGE_HEAD file generated? Is there any harm in leaving this file?\n\n> I would be of the opinion to stop calling \"git pull\" entirely, and use\n> \"git fetch and the git.move_branch show above. Unless I hear about\n> better ideas, my next patch set will be along those lines.\n\nOr replace the 'git pull' in the config file with 'git fetch && git\nreset --hard MERGE_HEAD'? I might be wrong though as I almost never\nuse git directly :-).\n\n-- \nCatalin\n"},{"id":"31784","messageId":"20070115233958.GF9761@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"b0943d9e0701151446l45eff9dbgcae718c1461d0725@mail.gmail.com","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-15T23:39:58Z","receivedAt":"2007-01-15T23:39:58Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, Jan 15, 2007 at 10:46:37PM +0000, Catalin Marinas wrote:\n> >I have started work on implementing \"stg pull --to \", but I'm\n> >facing some issues.\n> \n> I think the combination of 'pull' and '--to' is confusing (at least to\n> me) if you think of there English meaning.\n\nThat's possible, I'm not a native english speater :)\n\nThe idea is that we pull our stack from one place (current base) to\nanother. Another possiblity would have been \"stg rebase\", but I'm not\nvery keen on adding another command to do a very similar job.\n\n\n> > \"stg pull\", after popping all patches, currently calls \"git pull\",\n> > which indeed has 2 roles:\n> >\n> >- running \"git fetch\" on the parent branch\n> >- updating the head of the stack (which matches the base since\n> > no patch is applied), by relying on git-pull to fast-forward the\n> > stack head\n> \n> As Petr suggested at the OLS last year, I added the possibility to\n> configure the 'git pull' command so that people use whatever script\n> they like.\n\nRight. Maybe different workflows should have this option set to\ndifferent values in different repos ? I'm merely trying to get the\nbest default :)\n\n> >The latter is, unless I miss something:\n> >\n> >- overkill when what we want is just to move the head to another place\n> \n> Doesn't git automatically detect that it can do a fast forward? A\n> fetch is still necessary anyway.\n\nYes, it detects it when it is one. The problem is merely that it\ncan break things (for stgit's purpose) when it isn't.\n\n> I'm not sure how people intend to use StGIT. Some might have their own\n> changes to the base of the stack (maybe caused by 'stg commit') and\n> would want 'git pull' to do a proper merge and not just fast-forward.\n> \n> I actually did the above when maintaining a public (well, ARM internal\n> only currently) kernel branch for other people to pull from. Since\n> StGIT is not public branch friendly,\n\nMaking StGIT public-branch friendly is indeed the primary goal for\nthis set of patches - it is much less important to me to be able to\nbase my stack on GIT's \"pu\" or \"next\".\n\nThe idea is that, once we have are able to rebase a stack anyway,\nrebasing to the new tip of a branch that is an StGIT stack is in many\naspects only a particular case (modulo any unapplied patches).\n\n\n> I was working on a set of patches (mainly picking from other\n> branches and minor modifications) and just committing them when\n> finishing. Further updates from kernel.org triggered full merges\n> with the base.\n\nBut doing this means that you can end with a base that is not any more\non the parent branch, but on a local merge, right ? I'm not sure it\nis an easy thing to work with.\n\n\n> >- problematic when the parent branch is one that would be tracker with\n> >\"+\" in the remote pull line (eg. \"next\", \"pu\", or an stgit stack). In\n> >that case, although \"git fetch\" refuses to update the parent head\n> >because it would not be a fast-forward, git-pull then attempt to do a\n> >merge, which completely breaks expectations.\n> \n> Is there any way to configure git (via gitconfig) to behave\n> differently? You can add some per-branch options with the parent to\n> pull from but this would require separate .git/remotes/ files for each\n> branch.\n\nI'm not sure there is anything currently. The solution which I\nremember was proposed was that such a branch \"advertises\" its status\nin some way, so that the creator of the remote..fetch config\nentry can indeed insert the \"+\" itself automatically.\n\nOn the StGIT front, we could have \"stg clone\" look at\npatches//current or so, and then modify the\nremote..fetch entry accordingly. Or do you think of any\nworkflow that would break under this change ?\n\n\n> The switch() function already calls __set_head()\n\nYup, noticed that when running the testsuite - I meant to run switch\nthen reset instead.\n\n\n> > if os.path.isfile(os.path.join(basedir.get(), 'MERGE_HEAD')):\n> > os.remove(os.path.join(basedir.get(), 'MERGE_HEAD'))\n> \n> When is the MERGE_HEAD file generated? Is there any harm in leaving this \n> file?\n\nThis is a leftover from sources of inspiration that create_branch and\nswitch_branch were. I'm not 100% sure of why we want to get rid of\nit, but it looked like the situation was similar enough.\n\nIt is apparently generated by git-merge (and git-resolve), and\ncurrently out of the scope of stgit anyway. If we're moving our\nstack, it is probable it will loose any sort of accurateness.\n\nMaybe instead we would want to block stgit operations if we see it,\nbecause there certainly have been (illegal ?) operations done outside\nof StGIT.\n\n\n> >I would be of the opinion to stop calling \"git pull\" entirely, and use\n> >\"git fetch and the git.move_branch show above. Unless I hear about\n> >better ideas, my next patch set will be along those lines.\n> \n> Or replace the 'git pull' in the config file with 'git fetch && git\n> reset --hard MERGE_HEAD'? I might be wrong though as I almost never\n> use git directly :-).\n\nHm. Probably rather FETCH_HEAD. Will have to look at that - but see\nabove.\n\nFWIW, I now mostly have a patch to change from git-pull to git-fetch,\nwhich finally passes the current testsuite.\n\nNote that I did not think of using FETCH_HEAD, I was rather thinking\nof using information about the parent branch (which I had worked on\nrecently), with the idea that this info probably belongs to\nbranch..merge - which would complement Pavel's 87c69539 about\nbranch..remote.\n\nEven if we would not need it here, it would be good to have those 2\nparameters set when we can infer them. That reminds me that \"stg\nclone\" does not appear to allow selecting a specific branch in the\nparent repo (which explains why the .merge parameter is not so\ncrucially needed yet: we always clone the main branch).\n\nBest regards,\n-- \nYann.\n"},{"id":"31857","messageId":"b0943d9e0701161442t6b93e0d6nd88364600f2809ee@mail.gmail.com","threadId":"6319","inReplyTo":"20070115233958.GF9761@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Rebasing stgit stacks","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-01-16T22:42:17Z","receivedAt":"2007-01-16T22:42:17Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 15/01/07, Yann Dirson wrote:\n> On Mon, Jan 15, 2007 at 10:46:37PM +0000, Catalin Marinas wrote:\n> > >I have started work on implementing \"stg pull --to \", but I'm\n> > >facing some issues.\n> >\n> > I think the combination of 'pull' and '--to' is confusing (at least to\n> > me) if you think of there English meaning.\n>\n> That's possible, I'm not a native english speater :)\n\nI'm not either :-)\n\n> The idea is that we pull our stack from one place (current base) to\n> another. Another possiblity would have been \"stg rebase\", but I'm not\n> very keen on adding another command to do a very similar job.\n\nCan you give a typical example of what argument for --to is\nand what you repository looks like? I just want make sure I correctly\nunderstand the problem.\n\nI see the 'pull' command as a way to fetch the latest remote changes\nand merge them into the current branch (which would usually be a\nfast-forward). This command was meant as a stgit-aware 'git pull'.\n\n> > As Petr suggested at the OLS last year, I added the possibility to\n> > configure the 'git pull' command so that people use whatever script\n> > they like.\n>\n> Right. Maybe different workflows should have this option set to\n> different values in different repos ? I'm merely trying to get the\n> best default :)\n\nBut you want to replace the call to 'git pull' with 'git fetch'. I\nthink this is fine with my workflow but some people might actually\nrely on calling 'git pull' (or cg-pull).\n\n> > I was working on a set of patches (mainly picking from other\n> > branches and minor modifications) and just committing them when\n> > finishing. Further updates from kernel.org triggered full merges\n> > with the base.\n>\n> But doing this means that you can end with a base that is not any more\n> on the parent branch, but on a local merge, right ? I'm not sure it\n> is an easy thing to work with.\n\nYes, indeed, but this is probably the only way you can publish a\nbranch and still partially manage it with StGIT.\n\n> On the StGIT front, we could have \"stg clone\" look at\n> patches//current or so, and then modify the\n> remote..fetch entry accordingly. Or do you think of any\n> workflow that would break under this change ?\n\nCurrently, 'stg clone' just calls 'git clone' and initializes the\nmaster branch. There is no patches//current file as there is\nno current patch.\n\n> Even if we would not need it here, it would be good to have those 2\n> parameters set when we can infer them. That reminds me that \"stg\n> clone\" does not appear to allow selecting a specific branch in the\n> parent repo (which explains why the .merge parameter is not so\n> crucially needed yet: we always clone the main branch).\n\nI haven't looked at 'git clone' recently, can you select a specific branch?\n\n-- \nCatalin\n"},{"id":"31863","messageId":"20070116231735.GF7029@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"b0943d9e0701161442t6b93e0d6nd88364600f2809ee@mail.gmail.com","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-16T23:17:35Z","receivedAt":"2007-01-16T23:17:35Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Tue, Jan 16, 2007 at 10:42:17PM +0000, Catalin Marinas wrote:\n> >The idea is that we pull our stack from one place (current base) to\n> >another. Another possiblity would have been \"stg rebase\", but I'm not\n> >very keen on adding another command to do a very similar job.\n> \n> Can you give a typical example of what argument for --to is\n> and what you repository looks like? I just want make sure I correctly\n> understand the problem.\n\nMy example is quite similar to the one given by Guilhem: I had a git\nbranch coming from git-cvsimport, and my stgit stack forked atop that\nbranch. At some point git-cvsimport fucked something, and I\nregenerated a new mirror branch using it in a fresh repo. Then I\nwanted to rebase my stack on that new branch.\n\n\n> I see the 'pull' command as a way to fetch the latest remote changes\n> and merge them into the current branch (which would usually be a\n> fast-forward). This command was meant as a stgit-aware 'git pull'.\n\nDo you have an example of use where we would need a non-fast-forward\npull (supposing we have the \"pull --to\" functionality already, since I\nshall find time to finish soon).\n\n\n> >> As Petr suggested at the OLS last year, I added the possibility to\n> >> configure the 'git pull' command so that people use whatever script\n> >> they like.\n> >\n> >Right. Maybe different workflows should have this option set to\n> >different values in different repos ? I'm merely trying to get the\n> >best default :)\n> \n> But you want to replace the call to 'git pull' with 'git fetch'. I\n> think this is fine with my workflow but some people might actually\n> rely on calling 'git pull' (or cg-pull).\n\nRight, it may be possible (and I'd be interested in seeing such a\nworkflow). Maybe we could keep support for git-pull as an\nalternative.\n\nThis could be done, eg. by letting the user use \"pullcmd=git-pull\" and\nintroduce a new option like \"fastforward=\" triggering the\nfast-forward needed after git-fetch, with the default being \"true\",\nand the current behaviour being obtained by changing it to \"false\".\n\nThat would not add too much complexity, while setting the default to\nwhat I believe to match the most common workflows, and allow anyone\nrelying on the current behaviour to get it back.\n\n\n> >> I was working on a set of patches (mainly picking from other\n> >> branches and minor modifications) and just committing them when\n> >> finishing. Further updates from kernel.org triggered full merges\n> >> with the base.\n> >\n> >But doing this means that you can end with a base that is not any more\n> >on the parent branch, but on a local merge, right ? I'm not sure it\n> >is an easy thing to work with.\n> \n> Yes, indeed, but this is probably the only way you can publish a\n> branch and still partially manage it with StGIT.\n\nWell, I'd think that automatic rebasing would be a more elegant\nsolution.\n\n> >On the StGIT front, we could have \"stg clone\" look at\n> >patches//current or so, and then modify the\n> >remote..fetch entry accordingly. Or do you think of any\n> >workflow that would break under this change ?\n> \n> Currently, 'stg clone' just calls 'git clone' and initializes the\n> master branch. There is no patches//current file as there is\n> no current patch.\n\nI meant, the patches//current in the remote repo. If that one\nexist, then we should pull it with \"+\" as we should do for any\nrebasing remote branch.\n\n> >Even if we would not need it here, it would be good to have those 2\n> >parameters set when we can infer them. That reminds me that \"stg\n> >clone\" does not appear to allow selecting a specific branch in the\n> >parent repo (which explains why the .merge parameter is not so\n> >crucially needed yet: we always clone the main branch).\n> \n> I haven't looked at 'git clone' recently, can you select a specific branch?\n\nI had assumed so without looking, but it looks like you cannot select\nmuch. When using separate remotes, the HEAD in the clone is taken\nfrom the HEAD in the remote, and bears the same name. It is the only\nref created under heads/.\n\nWould there be some missing functionnality in git-clone, or am I just\nmissing something obvious ?\n\nBest regards,\n-- \nYann.\n"},{"id":"31865","messageId":"eojn5c$v9u$1@sea.gmane.org","threadId":"6319","inReplyTo":"20070116231735.GF7029@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Rebasing stgit stacks","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-16T23:30:18Z","receivedAt":"2007-01-16T23:30:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Yann Dirson wrote:\n\n> On Tue, Jan 16, 2007 at 10:42:17PM +0000, Catalin Marinas wrote:\n\n>>>The idea is that we pull our stack from one place (current base) to\n>>>another.  Another possiblity would have been \"stg rebase\", but I'm not\n>>>very keen on adding another command to do a very similar job.\n>> \n>> Can you give a typical example of what argument for --to is\n>> and what you repository looks like? I just want make sure I correctly\n>> understand the problem.\n> \n> My example is quite similar to the one given by Guilhem: I had a git\n> branch coming from git-cvsimport, and my stgit stack forked atop that\n> branch.  At some point git-cvsimport fucked something, and I\n> regenerated a new mirror branch using it in a fresh repo.  Then I\n> wanted to rebase my stack on that new branch.\n\nI'm all for calling this command \"stg rebase\". Currently you can do\n\"stg push -a; stg commit -a; git rebase; stg uncommit -n \"...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"31873","messageId":"20070117090313.GA9283@diana.vm.bytemark.co.uk","threadId":"6319","inReplyTo":"eojn5c$v9u$1@sea.gmane.org","subject":"Re: Rebasing stgit stacks","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-01-17T09:03:13Z","receivedAt":"2007-01-17T09:03:13Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-01-17 00:30:18 +0100, Jakub Narebski wrote:\n\n> Yann Dirson wrote:\n>\n> > My example is quite similar to the one given by Guilhem: I had a\n> > git branch coming from git-cvsimport, and my stgit stack forked\n> > atop that branch.  At some point git-cvsimport fucked something,\n> > and I regenerated a new mirror branch using it in a fresh repo.\n> > Then I wanted to rebase my stack on that new branch.\n>\n> I'm all for calling this command \"stg rebase\". Currently you can do\n> \"stg push -a; stg commit -a; git rebase; stg uncommit -n \"...\n\nOr simpler,\n\n stg pop -a\n git reset --hard \n stg push -n \n\nThis uses stgit for all operations that can conflict.\n\n(BTW, I've never seriously tried git rebase; does anyone have an\nopinion of how convenient its conflict handling is, compared to\nstgit's?)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"31876","messageId":"87y7o17vy6.fsf@morpheus.local","threadId":"6319","inReplyTo":"20070117090313.GA9283@diana.vm.bytemark.co.uk","subject":"Re: Rebasing stgit stacks","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-01-17T11:07:45Z","receivedAt":"2007-01-17T11:07:45Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Karl Hasselström writes:\n\n> On 2007-01-17 00:30:18 +0100, Jakub Narebski wrote:\n>\n>> Yann Dirson wrote:\n>>\n>> > My example is quite similar to the one given by Guilhem: I had a\n>> > git branch coming from git-cvsimport, and my stgit stack forked\n>> > atop that branch.  At some point git-cvsimport fucked something,\n>> > and I regenerated a new mirror branch using it in a fresh repo.\n>> > Then I wanted to rebase my stack on that new branch.\n>>\n>> I'm all for calling this command \"stg rebase\". Currently you can do\n>> \"stg push -a; stg commit -a; git rebase; stg uncommit -n \"...\n>\n> Or simpler,\n>\n> stg pop -a\n> git reset --hard \n> stg push -n \n>\n> This uses stgit for all operations that can conflict.\n>\n> (BTW, I've never seriously tried git rebase; does anyone have an\n> opinion of how convenient its conflict handling is, compared to\n> stgit's?)\n\nI have used it a little (together with git-svn), and one thing that\nconfused me was that when I got a conflict to resolve, it looked like\nthis:\n\n ...\n <<<<<<\n base version\n ======\n my version\n >>>>>>\n ...\n\nWhere \"my version\" is the code in the branch I'm rebasing, and\n\"base version\" is the code in the branch I'm rebasing on.\n\nThis is kind of opposite of how e.g. \"git pull\" works, where the first\nalternative is \"my version\". I guess it is an effect of the fact that\nyou are actually merging your branch into another, instead of the\nother way around.\n\n-- \nDavid Kågedal\n"},{"id":"31912","messageId":"20070117193406.GG9761@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"20070117090313.GA9283@diana.vm.bytemark.co.uk","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-17T19:34:06Z","receivedAt":"2007-01-17T19:34:06Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Wed, Jan 17, 2007 at 10:03:13AM +0100, Karl Hasselström wrote:\n> (BTW, I've never seriously tried git rebase; does anyone have an\n> opinion of how convenient its conflict handling is, compared to\n> stgit's?)\n\nWhen I was using it, it was much less convenient than stgit - required\nto forge a git-am command-line to continue after a conflict\n(--continue was added in April '06 - I had switched to StGIT before\nimplementing it myself ;). My evaluation at that point was that it\nrequired too much understanding of the plumbing issues to be shown to\na newbie - a problem which StGIT does not have. But I have not used\nit any more since then, and did not follow any improvements in this\nfield.\n\nStGIT features like \"push --undo\" also make it much easier to delay\nmerge of a given patch, and stack handling makes it easier to continue\nyour work after a night-break. Not to mention all goodies like patch\nreordering.\n\nBest regards,\n-- \nYann.\n"},{"id":"31922","messageId":"20070117205301.GH9761@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"eojn5c$v9u$1@sea.gmane.org","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-17T20:53:01Z","receivedAt":"2007-01-17T20:53:01Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote:\n> I'm all for calling this command \"stg rebase\".\n\nAfter all, my current implementation as \"pull --to\" mostly bypasses\nthe fetch, so it probably makes sense to use a new command.\n\nHowever, \"stg rebase \" does not sound right. I'm not very\nhappy with \"stg rebaseto \" (or rebase-to) either.\n\"stg rebase --to \" may feel strange too (command without\nnon-option arg), but may finally a good choice after all ? What do\nothers think ?\n\nBest regards,\n-- \nYann.\n"},{"id":"31923","messageId":"20070117213004.GI9761@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"20070115233958.GF9761@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-17T21:30:04Z","receivedAt":"2007-01-17T21:30:04Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Tue, Jan 16, 2007 at 12:39:58AM +0100, Yann Dirson wrote:\n> > >I would be of the opinion to stop calling \"git pull\" entirely, and use\n> > >\"git fetch and the git.move_branch show above. Unless I hear about\n> > >better ideas, my next patch set will be along those lines.\n> > \n> > Or replace the 'git pull' in the config file with 'git fetch && git\n> > reset --hard MERGE_HEAD'? I might be wrong though as I almost never\n> > use git directly :-).\n> \n> Hm. Probably rather FETCH_HEAD. Will have to look at that - but see\n> above.\n[...]\n> Note that I did not think of using FETCH_HEAD, I was rather thinking\n> of using information about the parent branch (which I had worked on\n> recently), with the idea that this info probably belongs to\n> branch..merge - which would complement Pavel's 87c69539 about\n> branch..remote.\n\nUnfortunately, using \"reset('FETCH_HEAD')\" or similar would not work.\nEg, in the case we have cloned an stgit branch as \"origin\", and the\nrevspec does not have a \"+\", git-fetch after a patch refresh in the\nremote repo still updates FETCH_HEAD even if it notices it cannot then\nfast-forward. With this we would end up with the \"origin\" branch not\nbeing changed, and our stack still being rebased as if we had a \"+\"\nrefspec, which would be quite inconsistent.\n\nBest regards,\n-- \nYann.\n"},{"id":"31951","messageId":"b0943d9e0701180105t7b01cb4di43b4db1fdc314bb7@mail.gmail.com","threadId":"6319","inReplyTo":"20070116231735.GF7029@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Rebasing stgit stacks","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-01-18T09:05:47Z","receivedAt":"2007-01-18T09:05:47Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 16/01/07, Yann Dirson wrote:\n> My example is quite similar to the one given by Guilhem: I had a git\n> branch coming from git-cvsimport, and my stgit stack forked atop that\n> branch. At some point git-cvsimport fucked something, and I\n> regenerated a new mirror branch using it in a fresh repo. Then I\n> wanted to rebase my stack on that new branch.\n\nAs Jakub said, I would also call this command 'rebase' instead of\n'pull --to', even if we duplicate a bit of code. It would make the\nimplementation even simpler as you won't break other people's\nworkflows using git-pull or cg-pull. The main feature of the 'pull'\ncommand is to fetch the latest changes from a remote repository and\nmerge (fast-forward) them into current base.\n\n> > But you want to replace the call to 'git pull' with 'git fetch'. I\n> > think this is fine with my workflow but some people might actually\n> > rely on calling 'git pull' (or cg-pull).\n>\n> Right, it may be possible (and I'd be interested in seeing such a\n> workflow). Maybe we could keep support for git-pull as an\n> alternative.\n\nAs I said, I use this myself on an exported branch.\n\n> This could be done, eg. by letting the user use \"pullcmd=git-pull\" and\n> introduce a new option like \"fastforward=\" triggering the\n> fast-forward needed after git-fetch, with the default being \"true\",\n> and the current behaviour being obtained by changing it to \"false\".\n\nBut isn't this too complicated when all you need is a 'rebase'-like command?\n\n> That would not add too much complexity, while setting the default to\n> what I believe to match the most common workflows, and allow anyone\n> relying on the current behaviour to get it back.\n\nThe problem is that I may use different workflows in the same\nrepository (but on different branches). Any new config options would\nhave to be per branch.\n\n-- \nCatalin\n"},{"id":"31966","messageId":"tnxmz4gv8sj.fsf@arm.com","threadId":"6319","inReplyTo":"20070117205301.GH9761@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Rebasing stgit stacks","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2007-01-18T12:06:20Z","receivedAt":"2007-01-18T12:06:20Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"Yann Dirson wrote:\n> On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote:\n>> I'm all for calling this command \"stg rebase\".\n>\n> After all, my current implementation as \"pull --to\" mostly bypasses\n> the fetch, so it probably makes sense to use a new command.\n>\n> However, \"stg rebase \" does not sound right. I'm not very\n> happy with \"stg rebaseto \" (or rebase-to) either.\n\nI think something 'stg rebase ' sounds OK.\n\n-- \nCatalin\n"},{"id":"32015","messageId":"20070118194208.GJ9761@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"tnxmz4gv8sj.fsf@arm.com","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-18T19:42:23Z","receivedAt":"2007-01-18T19:42:23Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Thu, Jan 18, 2007 at 12:06:20PM +0000, Catalin Marinas wrote:\n> Yann Dirson wrote:\n> > On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote:\n> >> I'm all for calling this command \"stg rebase\".\n> >\n> > After all, my current implementation as \"pull --to\" mostly bypasses\n> > the fetch, so it probably makes sense to use a new command.\n> >\n> > However, \"stg rebase \" does not sound right. I'm not very\n> > happy with \"stg rebaseto \" (or rebase-to) either.\n> \n> I think something 'stg rebase ' sounds OK.\n\nIt's just that it sounds more natural to me to give as instruction \"do\nrebase (current stack) to that point\" than \"do rebase that point\",\nwhich \"rebase \" would seem to imply.\n\nBest reagards,\n-- \nYann.\n"},{"id":"32021","messageId":"20070118205233.GK9761@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"b0943d9e0701180105t7b01cb4di43b4db1fdc314bb7@mail.gmail.com","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-18T20:52:33Z","receivedAt":"2007-01-18T20:52:33Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote:\n> But isn't this too complicated when all you need is a 'rebase'-like command?\n\nWell, I realize that I was not very clear in all this stuff. There\nare indeed 3 things I'm working on, but which are closely related to\neach other. One is rebasing to an arbitrary point; the second is\nforking an stgit stack out of another (possibly remote) stgit stack;\nthe third is that having \"stg pull\" use git-pull results for my\nworkflow in a purely broken situation.\n\nSince the 2nd is merely \"git-fetch then rebase to new head of remote\",\nand the 3rd is 100% fixed for me by using git-fetch instead of\ngit-pull, I tend to somewhat mix all those concepts and that surely\nshows in my mails.\n\nThat said, let me try to detangle all this :)\n\n> On 16/01/07, Yann Dirson wrote:\n> >My example is quite similar to the one given by Guilhem: I had a git\n> >branch coming from git-cvsimport, and my stgit stack forked atop that\n> >branch. At some point git-cvsimport fucked something, and I\n> >regenerated a new mirror branch using it in a fresh repo. Then I\n> >wanted to rebase my stack on that new branch.\n> \n> As Jakub said, I would also call this command 'rebase' instead of\n> 'pull --to', even if we duplicate a bit of code.\n> It would make the implementation even simpler\n\nA new command is fine with me, it's just that I feel \"rebase \"\nmay be confusing to beginners. I'd rather say \"rebase [] --to\n\", but it's just that I don't see the case for specifying a\ndifferent stack than the current one.\n\n\n> as you won't break other people's workflows using git-pull or\n> cg-pull. The main feature of the 'pull' command is to fetch the\n> latest changes from a remote repository and merge (fast-forward)\n> them into current base.\n\nHowever, this relates to the 2nd and 3rd items in my list, sorry to\nhave brought confusion here.\n\n\n> >> But you want to replace the call to 'git pull' with 'git fetch'. I\n> >> think this is fine with my workflow but some people might actually\n> >> rely on calling 'git pull' (or cg-pull).\n> >\n> >Right, it may be possible (and I'd be interested in seeing such a\n> >workflow). Maybe we could keep support for git-pull as an\n> >alternative.\n> \n> As I said, I use this myself on an exported branch.\n\nI've heard that, but I had understood that you used this because there\nwas nothing better available now, and that my second item (forking off\na public stgit-managed branch) would address your needs. If not, I\nmay have missed something.\n\n\n> >This could be done, eg. by letting the user use \"pullcmd=git-pull\" and\n> >introduce a new option like \"fastforward=\" triggering the\n> >fast-forward needed after git-fetch, with the default being \"true\",\n> >and the current behaviour being obtained by changing it to \"false\".\n> \n> >That would not add too much complexity, while setting the default to\n> >what I believe to match the most common workflows, and allow anyone\n> >relying on the current behaviour to get it back.\n> \n> The problem is that I may use different workflows in the same\n> repository (but on different branches). Any new config options would\n> have to be per branch.\n\nThat can be a serious point. But I fear we would start to seriously\nover-enginneer things here - unless the workflows that really require\nthe current behaviour are really widespread (again this assume I've\ncorrectly understood yours), wouldn't it be better to require the user\nto use one workflow per checkout, at least until such workflows are\nexplicited so we can support them at best ?\n\nBTW, I have started a couple of weeks ago to write things about patch\nmanagement and associated workflows in the GIT wiki [1]. This has a\nwider scope than just StGIT, and I have not finished to write down\neverything I wanted to, but that could be a place to start from.\nEspecially, I only listed a couple of workflows without extended\ndescription, and it would be great to have a page for each, with\nseveral ways to put them in action, with different sets of tools.\n\n[1] http://git.or.cz/gitwiki/PatchManagement\n\nBest regards,\n-- \nYann.\n"},{"id":"32049","messageId":"200701191040.17476.jnareb@gmail.com","threadId":"6319","inReplyTo":"20070117205301.GH9761@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Rebasing stgit stacks","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-19T09:40:16Z","receivedAt":"2007-01-19T09:40:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, Jan 17, 2007 Yann Dirson wrote:\n> On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote:\n\n>> I'm all for calling this command \"stg rebase\".\n> \n> After all, my current implementation as \"pull --to\" mostly bypasses\n> the fetch, so it probably makes sense to use a new command.\n> \n> However, \"stg rebase \" does not sound right. I'm not very\n> happy with \"stg rebaseto \" (or rebase-to) either.\n> \"stg rebase --to \" may feel strange too (command without\n> non-option arg), but may finally a good choice after all ? What do\n> others think ?\n\nFirst, \"stg rebase\" when on some git branch might mean rebase StGIT\nstack to head of current branch (because there were some git commits\non top of this branch). So it would be \"stg rebase [--onto ]\";\nit would be command without non-option arg, but this arg would be\noptional.\n\nSecond, if you were to implement separating commands into subcommands\n(perhaps just as alternative names) depending on what they act on:\n\"stg stack \", \"stg patch \" etc., this would\nI think belong to \"stg base \".\n-- \nJakub Narebski\nPoland\n"},{"id":"32050","messageId":"eoq439$7ml$1@sea.gmane.org","threadId":"6319","inReplyTo":"20070118205233.GK9761@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Rebasing stgit stacks","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-19T09:47:59Z","receivedAt":"2007-01-19T09:47:59Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Yann Dirson wrote:\n> On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote:\n\n>> As Jakub said, I would also call this command 'rebase' instead of\n>> 'pull --to', even if we duplicate a bit of code.\n>> It would make the implementation even simpler\n> \n> A new command is fine with me, it's just that I feel \"rebase \"\n> may be confusing to beginners.  I'd rather say \"rebase [] --to\n> \", but it's just that I don't see the case for specifying a\n> different stack than the current one.\n\nIf you want to move some stack from one branch to other, for example\nfrom 'next' or next-based branch to 'origin'/'master' or origin-based\nbranch you could do either:\n\n $ git checkout \n $ stg rebase \n\nor\n\n $ git checkout \n $ stg rebase --onto \n\n(or even \"stg rebase --onto \" or \"stg rebase \n--onto \").\n\nAlthough usually you have separate branch as StGIT stack \"base\", and\nyou can simply rebase git branch, then do\n\n $ stg rebase\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"32153","messageId":"20070120131716.GA4684@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"200701191040.17476.jnareb@gmail.com","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-20T13:17:17Z","receivedAt":"2007-01-20T13:17:17Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Jan 19, 2007 at 10:40:16AM +0100, Jakub Narebski wrote:\n> First, \"stg rebase\" when on some git branch might mean rebase StGIT\n> stack to head of current branch (because there were some git commits\n> on top of this branch). So it would be \"stg rebase [--onto ]\";\n> it would be command without non-option arg, but this arg would be\n> optional.\n\nI'm not sure I understand. Since the \"current StGIT stack\" is the one\npointed to by HEAD, how do you specify, when HEAD points to the target\nbranch, which stack to rebase ?\n\n> Second, if you were to implement separating commands into subcommands\n> (perhaps just as alternative names) depending on what they act on:\n> \"stg stack \", \"stg patch \" etc., this would\n> I think belong to \"stg base \".\n\nHm, the operation is not just about moving the stack base, it also has\nto reapply patches, so, whereas the central concept is about moving\nthe base, the whole operation is indeed about the rebaseing the whole\nstack.\n\nI'm not sure we need to expose the \"stack base\" to the user as an\nobject she could manipulate all alone, I'd rather think it should only\nbe kept a read-only attribute of the stack, which gets changed when\nthe user rebases the stack.\n\nIOW, the conceptual base object is private to the stack object, (it is\nindeed just a simple text attribute) and only stack methods are\nallowed to call base.move(), when they have ensured it can be done\nsafely (ie. popping all patches first).\n\nBest regards,\n-- \nYann.\n"},{"id":"32163","messageId":"200701202016.16333.jnareb@gmail.com","threadId":"6319","inReplyTo":"20070120131716.GA4684@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Rebasing stgit stacks","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-20T19:16:15Z","receivedAt":"2007-01-20T19:16:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Yann Dirson wrote:\n> On Fri, Jan 19, 2007 at 10:40:16AM +0100, Jakub Narebski wrote:\n\n>> First, \"stg rebase\" when on some git branch might mean rebase StGIT\n>> stack to head of current branch (because there were some git commits\n>> on top of this branch). So it would be \"stg rebase [--onto ]\";\n>> it would be command without non-option arg, but this arg would be\n>> optional.\n> \n> I'm not sure I understand. Since the \"current StGIT stack\" is the one\n> pointed to by HEAD, how do you specify, when HEAD points to the target\n> branch, which stack to rebase ?\n\nWell, I haven't thought this through. I was thinking about situation\nwhere there are no applied patches, and some commits were done without\nStGIT (pure git), i.e. we had\n\n ..1...2...3 <-- unapplied (deck) [ branch ]\n /\n a---b---c---d <-- HEAD [ branch ]\n\nThere were some git commits (for example fetch, or cherry-pick, or ...)\n\n\n ..1...2...3 <-- unapplied (deck) [ branch ]\n /\n a---b---c---d---e---f <-- HEAD [ branch ]\n\nAnd after \"stg rebase\" I want to have:\n\n\n ..1...2...3 <-- unapplied (deck) [ branch ]\n /\n a---b---c---d---e---f <-- HEAD [ branch ]\n\n\nI'm not sure how should the above work with applied patches\n(non-empty stack), i.e. with the following:\n\n ..3...4...5 <-- unapplied (deck) [ branch ]\n /\n a---b---c---d-.-1-.-2 <-- HEAD [ branch ]\n \\--v--/\n\n (stack) \n\nOr for example git branch got rebased, and I want to move also deck\n(unapplied patches), because \"git rebase\" don't move them... unless\nthis is not needed. Probably it is not needed.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"32169","messageId":"20070120200706.GC4684@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"200701202016.16333.jnareb@gmail.com","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-20T20:07:06Z","receivedAt":"2007-01-20T20:07:06Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sat, Jan 20, 2007 at 08:16:15PM +0100, Jakub Narebski wrote:\n> Yann Dirson wrote:\n> > On Fri, Jan 19, 2007 at 10:40:16AM +0100, Jakub Narebski wrote:\n> \n> >> First, \"stg rebase\" when on some git branch might mean rebase StGIT\n> >> stack to head of current branch (because there were some git commits\n> >> on top of this branch). So it would be \"stg rebase [--onto ]\";\n> >> it would be command without non-option arg, but this arg would be\n> >> optional.\n> > \n> > I'm not sure I understand. Since the \"current StGIT stack\" is the one\n> > pointed to by HEAD, how do you specify, when HEAD points to the target\n> > branch, which stack to rebase ?\n> \n> Well, I haven't thought this through. I was thinking about situation\n> where there are no applied patches, and some commits were done without\n> StGIT (pure git), i.e. we had\n> \n> ..1...2...3 <-- unapplied (deck) [ branch ]\n> /\n> a---b---c---d <-- HEAD [ branch ]\n> \n> There were some git commits (for example fetch, or cherry-pick, or ...)\n> \n> \n> ..1...2...3 <-- unapplied (deck) [ branch ]\n> /\n> a---b---c---d---e---f <-- HEAD [ branch ]\n> \n> And after \"stg rebase\" I want to have:\n> \n> \n> ..1...2...3 <-- unapplied (deck) [ branch ]\n> /\n> a---b---c---d---e---f <-- HEAD [ branch ]\n\nSo this what we typically currently get by using \"stg pull\n. branchname\", when HEAD is the stack branch.\n\nI can easily see that called as \"stg rebase\", with --to argument\ndefaulting to parent branch (as given by branch..merge) when the\nHEAD is the stack branch. That would be a neat replacement for \"stg\npull . \".\n\nCalling 'stg rebase' from the branch to rebase onto, however, can't\nguess which stack to rebase - there are possibly many stacks forked\noff your branch. In that case, you will need to ask \"stg rebase\n\".\n\nBut this will mean that \"stg rebase \" will have --to default\nto HEAD, whereas \"stg rebase\" will have --to default to the stack's\nparent branch. Not sure, but that looks a bit inconsistent, and may\nbe confusing. But probably we can implement things this way, and wait\nfor the user feedback to see if some restructuration is called,\npost-1.0, when we move to subcommands.\n\n\n> I'm not sure how should the above work with applied patches\n> (non-empty stack), i.e. with the following:\n> \n> ..3...4...5 <-- unapplied (deck) [ branch ]\n> /\n> a---b---c---d-.-1-.-2 <-- HEAD [ branch ]\n> \\--v--/\n> \n> (stack) \n\nAs long as commits occured as children of 'd', 'rebase' will take care\nof applied patches (it pops all patches first).\n\n> Or for example git branch got rebased, and I want to move also deck\n> (unapplied patches), because \"git rebase\" don't move them... unless\n> this is not needed. Probably it is not needed.\n\nThis is a typical ouse for \"stg rebase\", it should just work.\n\nBest regards,\n-- \nYann.\n"},{"id":"32315","messageId":"tnxirezueui.fsf@arm.com","threadId":"6319","inReplyTo":"eoq439$7ml$1@sea.gmane.org","subject":"Re: Rebasing stgit stacks","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2007-01-22T17:54:29Z","receivedAt":"2007-01-22T17:54:29Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"Jakub Narebski wrote:\n> Yann Dirson wrote:\n>> On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote:\n>\n>>> As Jakub said, I would also call this command 'rebase' instead of\n>>> 'pull --to', even if we duplicate a bit of code.\n>>> It would make the implementation even simpler\n>> \n>> A new command is fine with me, it's just that I feel \"rebase \"\n>> may be confusing to beginners.  I'd rather say \"rebase [] --to\n>> \", but it's just that I don't see the case for specifying a\n>> different stack than the current one.\n>\n> If you want to move some stack from one branch to other, for example\n> from 'next' or next-based branch to 'origin'/'master' or origin-based\n> branch you could do either:\n>\n> $ git checkout \n> $ stg rebase \n\nCurrently, in the StGIT terminology stack and branch are about the\nsame. If you want to move to a different stack, just use the \"stg\nbranch\" command.\n\nI think this should stay as it is since it gets confusing to have a\nname for a stack and a different name for a branch. A stack is just a\nbranch with stgit-specific metadata.\n\nIf is a branch and 'git checkout' causing to switch\nbranches, you end up on a different stack.\n\nWhat you'd probably want is a way to import patches from a different\nbranch/stack onto the newly checked out branch.\n\n> Although usually you have separate branch as StGIT stack \"base\", and\n> you can simply rebase git branch, then do\n>\n> $ stg rebase\n\nI only see the 'rebase' command as a shortcut for:\n\nstg pop -a\ngit reset --hard \nstg push -a (or just push the previously popped patches)\n\n-- \nCatalin\n\nP.S. could you cc me to your replies as I only read the GIT mailing\nlist via gmane and only when I'm at work (and usually work on StGIT at\nhome)\n"},{"id":"32322","messageId":"20070122194756.GA4083@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"tnxirezueui.fsf@arm.com","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-22T19:47:56Z","receivedAt":"2007-01-22T19:47:56Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, Jan 22, 2007 at 05:54:29PM +0000, Catalin Marinas wrote:\n> Jakub Narebski wrote:\n> > Yann Dirson wrote:\n> >> On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote:\n> >\n> >>> As Jakub said, I would also call this command 'rebase' instead of\n> >>> 'pull --to', even if we duplicate a bit of code.\n> >>> It would make the implementation even simpler\n> >> \n> >> A new command is fine with me, it's just that I feel \"rebase \"\n> >> may be confusing to beginners.  I'd rather say \"rebase [] --to\n> >> \", but it's just that I don't see the case for specifying a\n> >> different stack than the current one.\n> >\n> > If you want to move some stack from one branch to other, for example\n> > from 'next' or next-based branch to 'origin'/'master' or origin-based\n> > branch you could do either:\n> >\n> > $ git checkout \n> > $ stg rebase \n> \n> Currently, in the StGIT terminology stack and branch are about the\n> same. If you want to move to a different stack, just use the \"stg\n> branch\" command.\n\nI think you missed the point. StGIT stacks are usually forked off\nanother branch. As I understand it, Jakub talks about standard\nrebasing, ie. moving the stack base from its current parent branch to\na new one.\n\n\n> A stack is just a branch with stgit-specific metadata.\n\nI would rather say that an StGIT stacks uses a branch, but the stack\nis not the branch - eg, unapplied patches do not belong to the branch.\n\nIndeed I was thinking about that today, and thought that maybe it\nwould make sense not to use a head ref (and thus not using a real\nbranch), which would minimize the risk of someone committing by error\n(and thus minimize the need to use \"assimilate\"), since porcelainish\ncommit tools would then refuse to commit there.\n\n\n> What you'd probably want is a way to import patches from a different\n> branch/stack onto the newly checked out branch.\n\nSometimes you just want to throw out an obsolete branch and move your\nstack to a new baseline. That said, being able to duplicate a stack\n(and possibly rebasing it afterwards) would be useful as well.\n\n\n> > Although usually you have separate branch as StGIT stack \"base\", and\n> > you can simply rebase git branch, then do\n> >\n> > $ stg rebase\n\nOh, I think I understand - he probably uses \"base\" to refer to what I\ncall \"parent branch\", and not to the refs/bases/ reference...\n\nBest regards,\n-- \nyann.\n"},{"id":"32348","messageId":"b0943d9e0701221458r77b2b48hfa41d3dffcb848d0@mail.gmail.com","threadId":"6319","inReplyTo":"20070122194756.GA4083@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Rebasing stgit stacks","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-01-22T22:58:41Z","receivedAt":"2007-01-22T22:58:41Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 22/01/07, Yann Dirson wrote:\n> On Mon, Jan 22, 2007 at 05:54:29PM +0000, Catalin Marinas wrote:\n> > Currently, in the StGIT terminology stack and branch are about the\n> > same. If you want to move to a different stack, just use the \"stg\n> > branch\" command.\n>\n> I think you missed the point. StGIT stacks are usually forked off\n> another branch. As I understand it, Jakub talks about standard\n> rebasing, ie. moving the stack base from its current parent branch to\n> a new one.\n\nStGIT stacks are a series of volatile commits (commits) at the top of\na branch. The idea when I started writing this tool was that a series\nof applied patches would lead to the head of the current branch. The\nbranch and stack are tightly coupled and you cannot simply change the\nparent branch the stack is based on (not from a technical point but\nrather from conception one).\n\n> > A stack is just a branch with stgit-specific metadata.\n>\n> I would rather say that an StGIT stacks uses a branch, but the stack\n> is not the branch - eg, unapplied patches do not belong to the branch.\n\nThe unapplied patches can have any commit as a parent, either in the\ndirect history of the current branch or in any other branch, there is\nno restriction here. They get in line with the current branch's head\nduring the push operation.\n\n> Indeed I was thinking about that today, and thought that maybe it\n> would make sense not to use a head ref (and thus not using a real\n> branch), which would minimize the risk of someone committing by error\n> (and thus minimize the need to use \"assimilate\"), since porcelainish\n> commit tools would then refuse to commit there.\n\nBut isn't this what Quilt already does (i.e. a different mechanism for\npatches, on top of any SCM)?\n\nOne of the base ideas of StGIT is that the top patch represents the\nhead of the current branch and that the patches applied on the stack\nalways form the recent history of the current branch. I added the\ncommit command to have a way to freeze this state into the current\nbranch and no longer manage them with StGIT.\n\n> > What you'd probably want is a way to import patches from a different\n> > branch/stack onto the newly checked out branch.\n>\n> Sometimes you just want to throw out an obsolete branch and move your\n> stack to a new baseline. That said, being able to duplicate a stack\n> (and possibly rebasing it afterwards) would be useful as well.\n\nYou have 'branch --clone' (or --rename if you just want a different\nname) and now 'rebase'. As I said, the idea of moving the stack\n(patches) on top of a different branch should be done as an import (or\nmultiple cherry-pick or clone), otherwise we loose the coupling\nbetween branches and stacks.\n\n> > > Although usually you have separate branch as StGIT stack \"base\", and\n> > > you can simply rebase git branch, then do\n> > >\n> > > $ stg rebase\n>\n> Oh, I think I understand - he probably uses \"base\" to refer to what I\n> call \"parent branch\", and not to the refs/bases/ reference...\n\nThe ref/bases/ is not used much in StGIT. I initially added it\nas a way to see the base of a stack in gitk but that's probably the\nonly usecase.\n\n-- \nCatalin\n"},{"id":"32349","messageId":"b0943d9e0701221512g377b26b9rf6eabdcdd24853ff@mail.gmail.com","threadId":"6319","inReplyTo":"200701202016.16333.jnareb@gmail.com","subject":"Re: Rebasing stgit stacks","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-01-22T23:12:05Z","receivedAt":"2007-01-22T23:12:05Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 20/01/07, Jakub Narebski wrote:\n> Well, I haven't thought this through. I was thinking about situation\n> where there are no applied patches, and some commits were done without\n> StGIT (pure git), i.e. we had\n>\n> ..1...2...3 <-- unapplied (deck) [ branch ]\n> /\n> a---b---c---d <-- HEAD [ branch ]\n>\n> There were some git commits (for example fetch, or cherry-pick, or ...)\n>\n>\n> ..1...2...3 <-- unapplied (deck) [ branch ]\n> /\n> a---b---c---d---e---f <-- HEAD [ branch ]\n>\n> And after \"stg rebase\" I want to have:\n>\n>\n> ..1...2...3 <-- unapplied (deck) [ branch ]\n> /\n> a---b---c---d---e---f <-- HEAD [ branch ]\n\nStGIT currently doesn't care whether the base of an empty stack has\nchanged. To get to the above graph, just use \"stg push 1..3\" and \"stg\npop 1..3\".\n\nThe unapplied patches may be disconnected from the current graph and\nStGIT doesn't care about them until pushed (applied) on top of the\nstack when they become part of the linear history graph. I'm not good\nat ASCII graphics to show an example but, for example, as long as they\nare unapplied, 1 above can have b as a parent and 2 can have e as a\nparent (it all depends on when they were last pushed).\n\n-- \nCatalin\n"},{"id":"32369","messageId":"20070123074945.GB4083@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"b0943d9e0701221458r77b2b48hfa41d3dffcb848d0@mail.gmail.com","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-23T07:49:45Z","receivedAt":"2007-01-23T07:49:45Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote:\n> On 22/01/07, Yann Dirson wrote:\n> >On Mon, Jan 22, 2007 at 05:54:29PM +0000, Catalin Marinas wrote:\n> >> Currently, in the StGIT terminology stack and branch are about the\n> >> same. If you want to move to a different stack, just use the \"stg\n> >> branch\" command.\n> >\n> >I think you missed the point. StGIT stacks are usually forked off\n> >another branch. As I understand it, Jakub talks about standard\n> >rebasing, ie. moving the stack base from its current parent branch to\n> >a new one.\n> \n> StGIT stacks are a series of volatile commits (commits) at the top of\n> a branch. The idea when I started writing this tool was that a series\n> of applied patches would lead to the head of the current branch. The\n> branch and stack are tightly coupled and you cannot simply change the\n> parent branch the stack is based on (not from a technical point but\n> rather from conception one).\n\nWell, that's now allowed by \"rebase\".\n\n> >> A stack is just a branch with stgit-specific metadata.\n> >\n> >I would rather say that an StGIT stacks uses a branch, but the stack\n> >is not the branch - eg, unapplied patches do not belong to the branch.\n> \n> The unapplied patches can have any commit as a parent, either in the\n> direct history of the current branch or in any other branch, there is\n> no restriction here. They get in line with the current branch's head\n> during the push operation.\n\nRight. I'm just emphasizing that, since they are (even temporarily)\nnot part of the GIT branch from a GIT point of view, but part of the\nstack, the 2 concepts, while closely linked, are not strict subsets of\neach other. Rather, they share some common points, but neither would\nbe parent of the other in a class hierarchy.\n\n> >Indeed I was thinking about that today, and thought that maybe it\n> >would make sense not to use a head ref (and thus not using a real\n> >branch), which would minimize the risk of someone committing by error\n> >(and thus minimize the need to use \"assimilate\"), since porcelainish\n> >commit tools would then refuse to commit there.\n> \n> But isn't this what Quilt already does (i.e. a different mechanism for\n> patches, on top of any SCM)?\n\nI'm not sure wat you mean here. I'm only talking of StGIT and the GIT\nworld here.\n\n> One of the base ideas of StGIT is that the top patch represents the\n> head of the current branch and that the patches applied on the stack\n> always form the recent history of the current branch.\n\nI'm not willing to change the concept. I'm just wondering whether\nusing a non-head reference (eg. stacks/ or stacks//top)\nwould not be better. For this we may need to consider using detached\nHEAD support from 1.5.0, but I'm just thinking loudly, I have not\nlooked at what that thing provides exactly yet.\n\n> I added the commit command to have a way to freeze this state into\n> the current branch and no longer manage them with StGIT.\n\n\n> >> What you'd probably want is a way to import patches from a different\n> >> branch/stack onto the newly checked out branch.\n> >\n> >Sometimes you just want to throw out an obsolete branch and move your\n> >stack to a new baseline. That said, being able to duplicate a stack\n> >(and possibly rebasing it afterwards) would be useful as well.\n> \n> You have 'branch --clone' (or --rename if you just want a different\n> name) and now 'rebase'.\n\nD'oh. I was probably expecting \"stack --clone\" or something :)\n\n> As I said, the idea of moving the stack (patches) on top of a\n> different branch should be done as an import (or multiple\n> cherry-pick or clone), otherwise we loose the coupling between\n> branches and stacks.\n\nI'll have to think more about that - I'm not sure I get you point. By\nmoving/cloning we keep (or could keep) the patches' history. By\nimporting we cannot do that.\n\nBest regards,\n-- \nYann.\n"},{"id":"32459","messageId":"b0943d9e0701231403qefb28f0h91d3f599699b9908@mail.gmail.com","threadId":"6319","inReplyTo":"20070123074945.GB4083@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Rebasing stgit stacks","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-01-23T22:03:26Z","receivedAt":"2007-01-23T22:03:26Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 23/01/07, Yann Dirson wrote:\n> On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote:\n> > On 22/01/07, Yann Dirson wrote:\n> > The unapplied patches can have any commit as a parent, either in the\n> > direct history of the current branch or in any other branch, there is\n> > no restriction here. They get in line with the current branch's head\n> > during the push operation.\n>\n> Right. I'm just emphasizing that, since they are (even temporarily)\n> not part of the GIT branch from a GIT point of view, but part of the\n> stack, the 2 concepts, while closely linked, are not strict subsets of\n> each other. Rather, they share some common points, but neither would\n> be parent of the other in a class hierarchy.\n\nIndeed, but my point is that they are really tightly coupled and not\neasy to disconnect in the current design. Maybe we could loose the\ncoupling post 1.0 but I'm not convinced it wouldn't create confusion\namong users. I also don't think there would be many users wanting to\nmove a stack on top of a different branch when some import or multiple\ncherry-picking would be enough.\n\n> > >Indeed I was thinking about that today, and thought that maybe it\n> > >would make sense not to use a head ref (and thus not using a real\n> > >branch), which would minimize the risk of someone committing by error\n> > >(and thus minimize the need to use \"assimilate\"), since porcelainish\n> > >commit tools would then refuse to commit there.\n> >\n> > But isn't this what Quilt already does (i.e. a different mechanism for\n> > patches, on top of any SCM)?\n>\n> I'm not sure wat you mean here. I'm only talking of StGIT and the GIT\n> world here.\n\nI got the (wrong) impression that you'd like to disconnect StGIT\npatches from GIT commits which would mean re-writing Quilt or some\nother form of patch management.\n\n> > One of the base ideas of StGIT is that the top patch represents the\n> > head of the current branch and that the patches applied on the stack\n> > always form the recent history of the current branch.\n>\n> I'm not willing to change the concept. I'm just wondering whether\n> using a non-head reference (eg. stacks/ or stacks//top)\n> would not be better. For this we may need to consider using detached\n> HEAD support from 1.5.0, but I'm just thinking loudly, I have not\n> looked at what that thing provides exactly yet.\n\nIt might be a good idea (probably post 1.0) since we have a 'commit'\ncommand to update the head of the branch already. I'll have to think a\nbit more to make sure it doesn't break existing use-cases. I also\nhaven't followed the detached HEAD support. StGIT currently relies on\nthe HEAD giving the information about the current branch.\n\n> > As I said, the idea of moving the stack (patches) on top of a\n> > different branch should be done as an import (or multiple\n> > cherry-pick or clone), otherwise we loose the coupling between\n> > branches and stacks.\n>\n> I'll have to think more about that - I'm not sure I get you point. By\n> moving/cloning we keep (or could keep) the patches' history. By\n> importing we cannot do that.\n\nThe 'pick' command could be (easily) fixed to preserve the history of\na patch (I'll add this to the todo list). The log commit would have\nthe picked patch's log as a parent rather than none.\n\nStGIT grew up almost (or just 2 months behind) at the same time with\nGIT with a lot experimental/prototype features implemented. Now we\nprobably have a lot more ideas (and users) about how we should use GIT\nand StGIT and can re-design parts of StGIT to accommodate the new\nuse-cases. As I said, I'll first like to get a 1.0 out this spring.\n\n-- \nCatalin\n"},{"id":"32464","messageId":"20070124000551.GC4083@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"b0943d9e0701231403qefb28f0h91d3f599699b9908@mail.gmail.com","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-24T00:05:51Z","receivedAt":"2007-01-24T00:05:51Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Tue, Jan 23, 2007 at 10:03:26PM +0000, Catalin Marinas wrote:\n> >I'll have to think more about that - I'm not sure I get you point. By\n> >moving/cloning we keep (or could keep) the patches' history. By\n> >importing we cannot do that.\n> \n> The 'pick' command could be (easily) fixed to preserve the history of\n> a patch (I'll add this to the todo list). The log commit would have\n> the picked patch's log as a parent rather than none.\n\nRight - \"branch --clone\" could also use that (or maybe it does already\nby design). Together with this, \"pick --fold\" and possibly \"sync\"\n(although I never used the latter so I'm not 100% sure how it works)\ncould register a merge, and sometime in the future we could use this\ninformation to be able to do some merging. I'm not going to look\ninto this soon, but I have this popping out regularly in my head ;)\n\n\n> As I said, I'll first like to get a 1.0 out this spring.\n\nYes. Maybe we should get 0.12 out of the door soon, with some more\nbugs fixed. I'm trying to finish putting out in a decent shape stuff\nabout parent branches, git-fetch use and the other related issues\nmentionned those last days. Maybe that will be ready before enough\nbugs are squashed for 0.12, but maybe not :)\n\nBest regards,\n-- \nyann.\n"},{"id":"32514","messageId":"b0943d9e0701240437l33a53f64tfea8267b78bff421@mail.gmail.com","threadId":"6319","inReplyTo":"20070124000551.GC4083@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Rebasing stgit stacks","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-01-24T12:37:15Z","receivedAt":"2007-01-24T12:37:15Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 24/01/07, Yann Dirson wrote:\n> On Tue, Jan 23, 2007 at 10:03:26PM +0000, Catalin Marinas wrote:\n> > >I'll have to think more about that - I'm not sure I get you point. By\n> > >moving/cloning we keep (or could keep) the patches' history. By\n> > >importing we cannot do that.\n> >\n> > The 'pick' command could be (easily) fixed to preserve the history of\n> > a patch (I'll add this to the todo list). The log commit would have\n> > the picked patch's log as a parent rather than none.\n>\n> Right - \"branch --clone\" could also use that (or maybe it does already\n> by design). Together with this, \"pick --fold\" and possibly \"sync\"\n> (although I never used the latter so I'm not 100% sure how it works)\n> could register a merge, and sometime in the future we could use this\n> information to be able to do some merging. I'm not going to look\n> into this soon, but I have this popping out regularly in my head ;)\n\n'sync' is still experimental. I usually have the same patches on\ndifferent branches (i.e. a stable kernel branch for customers and a\nmore up-to-date branch for pushing patches upstream). I wanted a way\nto automatically synchronise the changes made to some patches found in\nboth branches. This command folds the remote patch onto the current\none using a three-way merge. If they are identical, the current patch\nshouldn't change. If they are not identical, it leads to conflicts\nthat have to be manually solved.\n\n> > As I said, I'll first like to get a 1.0 out this spring.\n>\n> Yes. Maybe we should get 0.12 out of the door soon, with some more\n> bugs fixed. I'm trying to finish putting out in a decent shape stuff\n> about parent branches, git-fetch use and the other related issues\n> mentionned those last days. Maybe that will be ready before enough\n> bugs are squashed for 0.12, but maybe not :)\n\nMaybe I'll manage to get a new release out in about a week or so.\n\n-- \nCatalin\n"},{"id":"32551","messageId":"20070124200339.GA4036@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"b0943d9e0701240437l33a53f64tfea8267b78bff421@mail.gmail.com","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-24T20:03:39Z","receivedAt":"2007-01-24T20:03:39Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Wed, Jan 24, 2007 at 12:37:15PM +0000, Catalin Marinas wrote:\n> >Right - \"branch --clone\" could also use that (or maybe it does already\n> >by design). Together with this, \"pick --fold\" and possibly \"sync\"\n> >(although I never used the latter so I'm not 100% sure how it works)\n> >could register a merge, and sometime in the future we could use this\n> >information to be able to do some merging. I'm not going to look\n> >into this soon, but I have this popping out regularly in my head ;)\n> \n> 'sync' is still experimental. I usually have the same patches on\n> different branches (i.e. a stable kernel branch for customers and a\n> more up-to-date branch for pushing patches upstream).\n\nThat sounds like a typical usecase we should document :)\n\n> I wanted a way to automatically synchronise the changes made to some\n> patches found in both branches. This command folds the remote patch\n> onto the current one using a three-way merge. If they are identical,\n> the current patch shouldn't change. If they are not identical, it\n> leads to conflicts that have to be manually solved.\n\nSo, indeed \"sync\" is a kind of merge tool already. It could be a good\nstart to implement merging of forked patches. But going further would\nprobably require to further develop the technics to work with patches\nof patches.\n\nbest regards,\n-- \nYann.\n"},{"id":"32899","messageId":"20070128043312.GG9897@thunk.org","threadId":"6319","inReplyTo":"b0943d9e0701221458r77b2b48hfa41d3dffcb848d0@mail.gmail.com","subject":"Re: Rebasing stgit stacks","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-01-28T04:33:12Z","receivedAt":"2007-01-28T04:33:12Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote:\n> StGIT stacks are a series of volatile commits (commits) at the top of\n> a branch. The idea when I started writing this tool was that a series\n> of applied patches would lead to the head of the current branch. The\n> branch and stack are tightly coupled and you cannot simply change the\n> parent branch the stack is based on (not from a technical point but\n> rather from conception one).\n\nWell, a typical use case for me is:\n\n\tstg branch master\n\tgit pull .\n\tstg branch 2.6.20-rc5\n\tstg export -d /tmp/temp-stack\n\tstg branch master\n\tstg branch -C 2.6.20-rc6\n\tstg import -s /tmp/temp-stack/series \n\nThat's because I want to keep the original patch series for\n2.6.20-rc5, but I also want rebase the patch set to 2.6.20-rc6. Is\nthere a better way of doing this? \n\n\t\t\t\t\t\t- Ted\n"},{"id":"32912","messageId":"20070128102552.GF4036@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6319","inReplyTo":"20070128043312.GG9897@thunk.org","subject":"Re: Rebasing stgit stacks","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-28T10:25:52Z","receivedAt":"2007-01-28T10:25:52Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sat, Jan 27, 2007 at 11:33:12PM -0500, Theodore Tso wrote:\n> On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote:\n> > StGIT stacks are a series of volatile commits (commits) at the top of\n> > a branch. The idea when I started writing this tool was that a series\n> > of applied patches would lead to the head of the current branch. The\n> > branch and stack are tightly coupled and you cannot simply change the\n> > parent branch the stack is based on (not from a technical point but\n> > rather from conception one).\n> \n> Well, a typical use case for me is:\n> \n> \tstg branch master\n> \tgit pull .\n> \tstg branch 2.6.20-rc5\n> \tstg export -d /tmp/temp-stack\n> \tstg branch master\n> \tstg branch -C 2.6.20-rc6\n\nYou mean lowercase \"-c\", right ?\n\n> \tstg import -s /tmp/temp-stack/series \n> \n> That's because I want to keep the original patch series for\n> 2.6.20-rc5, but I also want rebase the patch set to 2.6.20-rc6. Is\n> there a better way of doing this? \n\nYes. First, you can clone your stack:\n\nstgit$ stg branch --clone copy\nCloning current branch to \"copy\"... done\nstgit$ stg branch -l\nAvailable branches:\n> s copy | clone of \"master\"\n s master | \n origin | \n\nAnd then you can rebase the clone, either with \"stg rebase\" (in stg\nHEAD only), or use the small tip described at\nhttp://git.or.cz/gitwiki/GitTips#head-8e71c3bdda0c372b79e33f5a3fedaf22c4c6f944\n\nBest regards,\n-- \nYann.\n"},{"id":"32935","messageId":"b0943d9e0701281521i60da11dfscd8649f56960730d@mail.gmail.com","threadId":"6319","inReplyTo":"20070128043312.GG9897@thunk.org","subject":"Re: Rebasing stgit stacks","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-01-28T23:21:19Z","receivedAt":"2007-01-28T23:21:19Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 28/01/07, Theodore Tso wrote:\n> Well, a typical use case for me is:\n>\n> stg branch master\n> git pull .\n> stg branch 2.6.20-rc5\n> stg export -d /tmp/temp-stack\n> stg branch master\n> stg branch -C 2.6.20-rc6\n> stg import -s /tmp/temp-stack/series\n>\n> That's because I want to keep the original patch series for\n> 2.6.20-rc5, but I also want rebase the patch set to 2.6.20-rc6. Is\n> there a better way of doing this?\n\nAs Yann pointed out, you could just clone 2.6.20-rc5 into 2.6.20-rc6\nand rebase the latter (currently with 'stg rebase v2.6.20-rc6').\n\nIf you have the branches already created, you can avoid the\nexport/import with a cherry-pick (with better merging than just\napplying a patch). The 'pick' command only takes an argument (I'd like\nto extend it to accept multiple or patch ranges) but you can use it\nwith 'series':\n\nstg branch 2.6.20-rc6\nstg series -b 2.6.20-rc5 --noprefix --showbranch [patches...] \\\n | xargs -rn1 stg pick\n\nYou could even use the --missing instead of -b for the series command.\nThis option shows the patches on the remote branch which are missing\nin current. Pretty useful if you want to continue importing after\nfixing a conflict for example (that's a reason why I haven't extended\n'pick' yet, 'series -m' seemed pretty powerful).\n\nAnother trick if you modify some patches in one branch (i.e.\n2.6.20-rc5) is to use 'stg sync -b 2.6.20-rc5 [patches]' in the other\nbranch. It tries a three-way merge of each individual patch with the\ncorresponding one in the other branch, showing you any possible\nconflicts (I usually have 'imerger' set to emacs... and 'autoimerge'\nto 'yes' in the config file so that emacs' ediff is automatically\ninvoked for every conflict).\n\n-- \nCatalin\n"}]}