{"thread":{"id":"13852","subject":"stg pull/rebase","startedAt":"2008-06-07T17:22:02Z","lastAt":"2008-06-11T19:07:32Z","messageCount":9,"participants":["Karl Hasselström","Jakub Narebski","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"79059","messageId":"20080607172202.GA5179@diana.vm.bytemark.co.uk","threadId":"13852","inReplyTo":null,"subject":"stg pull/rebase","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-06-07T17:22:02Z","receivedAt":"2008-06-07T17:22:02Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"As I said, I've been thinking a bit about stg pull and stg rebase\nrecently (though I haven't written any code; I don't want to be\njuggling too many balls at once).\n\nCurrently, there's stg rebase which only does rebasing, and stg pull\nwhich does either rebase or merge depending on a config option. And on\ntop of that there's config stuff like stgit.pullcmd that is invoked in\nsome cases but not others.\n\nWhat I think I'd like is the following:\n\n * Just one command, stg pull. stg rebase is removed.\n\n * When pull is invoked, the following happens:\n\n 1. The branch we pull from may be updated, depending on the\n configuration. (e.g. git fetch or git svn fetch)\n\n 2. Depending on the configuration (overridable by the\n --fast-forward, --rebase, and --merge options), one of these\n three things happen:\n\n 1. We pop all patches, fast-forward to the new base, and push\n them back. If it's not a fast-forward, we error out.\n\n 2. We pop all patches, reset to the new base, and push them\n back.\n\n 3. We pop all patches, merge with the other branch, then push\n the patches back.\n\n Fast-forward is the default if no configuration or command-line\n flag is given.\n\nI've personally never had a need for the merge case, but I recall you\narguing to keep it, Catalin?\n\nThe benefits of this organisation are\n\n * Configuration of how to update the remote prior to pulling and\n ff/rebase/merge configuration are orthogonal.\n\n * The default action is to fast-forward, which is probably what most\n users want -- merge is very likely to do the wrong thing, and\n rebase can lose changes.\n\n * The remote updating is entirely separated from the actual pushing\n and popping of patches, since it runs to completion before we do\n anything else. This means that we can pop, change the base and\n push in a single transaction.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"79060","messageId":"m3y75hw3an.fsf@localhost.localdomain","threadId":"13852","inReplyTo":"20080607172202.GA5179@diana.vm.bytemark.co.uk","subject":"Re: stg pull/rebase","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-07T17:41:41Z","receivedAt":"2008-06-07T17:41:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Karl Hasselström writes:\n\n> Currently, there's stg rebase which only does rebasing, and stg pull\n> which does either rebase or merge depending on a config option. And on\n> top of that there's config stuff like stgit.pullcmd that is invoked in\n> some cases but not others.\n> \n> What I think I'd like is the following:\n> \n> * Just one command, stg pull. stg rebase is removed.\n\nAnd I would have to learn to use other command (I use very frequently\nthe following sequence: git remote update && stg rebase )?\nNot nice.\n \nI already have to use two commands: \"stg refresh && stg edit\" to make\na change which affects how commit message is written, instead of\nsimplier \"stg refresh --edit\".\n\n> * When pull is invoked, the following happens:\n> \n> 1. The branch we pull from may be updated, depending on the\n> configuration. (e.g. git fetch or git svn fetch)\n> \n> 2. Depending on the configuration (overridable by the\n> --fast-forward, --rebase, and --merge options), one of these\n> three things happen:\n\nCouldn't then \"stg rebase\" be 'internal alias' to \"git pull --rebase\"?\n\n[...]\n> * The default action is to fast-forward, which is probably what most\n> users want -- merge is very likely to do the wrong thing, and\n> rebase can lose changes.\n\nUnless you want to rebase on top of different branch, for example\nmoving stack from 'master' to 'next', or when you work on top of\nbranch which doesn't fast-forward, like 'pu' in git repository.\n \n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"79065","messageId":"20080607190848.GA7853@diana.vm.bytemark.co.uk","threadId":"13852","inReplyTo":"m3y75hw3an.fsf@localhost.localdomain","subject":"Re: stg pull/rebase","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-06-07T19:08:48Z","receivedAt":"2008-06-07T19:08:48Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-06-07 10:41:41 -0700, Jakub Narebski wrote:\n\n> Karl Hasselström writes:\n>\n> > * Just one command, stg pull. stg rebase is removed.\n>\n> And I would have to learn to use other command (I use very\n> frequently the following sequence: git remote update && stg rebase\n> )? Not nice.\n\nRight. We could keep \"stg rebase\" for backwards compatibility. (It\nwould mean stg pull --rebase.) I like to complain about the too-large\nnumber of stg subcommands, but upset users are even less desirable ...\n:-)\n\n> I already have to use two commands: \"stg refresh && stg edit\" to\n> make a change which affects how commit message is written, instead\n> of simplier \"stg refresh --edit\".\n\nYes, sorry about that. You have pointed it out before, and I've been\nmeaning to fix it.\n\n> > 2. Depending on the configuration (overridable by the\n> > --fast-forward, --rebase, and --merge options), one of these\n> > three things happen:\n>\n> Couldn't then \"stg rebase\" be 'internal alias' to \"git pull\n> --rebase\"?\n\nAbsolutely.\n\n> > * The default action is to fast-forward, which is probably what\n> > most users want -- merge is very likely to do the wrong thing,\n> > and rebase can lose changes.\n>\n> Unless you want to rebase on top of different branch, for example\n> moving stack from 'master' to 'next', or when you work on top of\n> branch which doesn't fast-forward, like 'pu' in git repository.\n\nYes, definitely. rebase would stay a \"first-class citizen\". But I\nreally do think that having fast-forward as an option is nice; in many\ncases you build on top of a non-rebasing branch, and having the tool\nverify that you don't lose commits is a good thing.\n\nAnd when the user says just \"stg pull\" (having configured nothing)\nit's probably best to default to the simplest and safest of the three:\nfast-forward. If the user wants \"rebase\", it'd be available either\nwith the command-line option or with a (per-branch) config file\nsetting.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"79331","messageId":"b0943d9e0806100302j159f5b7fq6d970316b902b39b@mail.gmail.com","threadId":"13852","inReplyTo":"20080607172202.GA5179@diana.vm.bytemark.co.uk","subject":"Re: stg pull/rebase","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2008-06-10T10:02:18Z","receivedAt":"2008-06-10T10:02:18Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"2008/6/7 Karl Hasselström :\n> As I said, I've been thinking a bit about stg pull and stg rebase\n> recently (though I haven't written any code; I don't want to be\n> juggling too many balls at once).\n>\n> Currently, there's stg rebase which only does rebasing, and stg pull\n> which does either rebase or merge depending on a config option. And on\n> top of that there's config stuff like stgit.pullcmd that is invoked in\n> some cases but not others.\n\nThis would need some clean-up indeed or maybe better documentation.\nThey might be a bit difficult and I have to look at the code from time\nto time. However, I found some these policies useful. For example, I\njust do a \"stg pull\" from a Subversion repository with the config\nbelow:\n\n[stgit]\n pull-policy = fetch-rebase\n fetchcmd = git svn fetch\n rebasecmd = git svn rebase\n\n> What I think I'd like is the following:\n>\n> * Just one command, stg pull. stg rebase is removed.\n\nI still find \"rebase\" useful and use it in some situations when I\ndon't need a pull. As Jakub mentioned, maybe we could keep the\n\"rebase\" functionality outside of the \"pull\" command (make it part of\nStack with a corresponding Branch.rebase?) and have \"rebase\" use it.\n\n> * When pull is invoked, the following happens:\n>\n> 1. The branch we pull from may be updated, depending on the\n> configuration. (e.g. git fetch or git svn fetch)\n\nOK.\n\n> 2. Depending on the configuration (overridable by the\n> --fast-forward, --rebase, and --merge options), one of these\n> three things happen:\n\nBut \"pull\" always suggests fetching something. Adding \"--rebase\" would\nmean that it doesn't fetch. Shouldn't we leave this functionality to\n\"rebase\" only?\n\n> 1. We pop all patches, fast-forward to the new base, and push\n> them back. If it's not a fast-forward, we error out.\n>\n> 2. We pop all patches, reset to the new base, and push them\n> back.\n>\n> 3. We pop all patches, merge with the other branch, then push\n> the patches back.\n\nThese are OK, with the comment on have rebase functionality in \"rebase\" only.\n\n> Fast-forward is the default if no configuration or command-line\n> flag is given.\n\nOK.\n\n> I've personally never had a need for the merge case, but I recall you\n> arguing to keep it, Catalin?\n\nI don't use it either but there might be people that have complicated\nconfigurations and they mix Git commits with StGIT patches. Not sure\nthough.\n\n-- \nCatalin\n"},{"id":"79335","messageId":"20080610104244.GC30119@diana.vm.bytemark.co.uk","threadId":"13852","inReplyTo":"b0943d9e0806100302j159f5b7fq6d970316b902b39b@mail.gmail.com","subject":"Re: stg pull/rebase","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-06-10T10:42:44Z","receivedAt":"2008-06-10T10:42:44Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-06-10 11:02:18 +0100, Catalin Marinas wrote:\n\n> However, I found some these policies useful. For example, I just do\n> a \"stg pull\" from a Subversion repository with the config below:\n>\n> [stgit]\n> pull-policy = fetch-rebase\n> fetchcmd = git svn fetch\n> rebasecmd = git svn rebase\n\nLooks useful.\n\nBut what exactly is \"rebasecmd\" useful for, when you already have\n\"fetchcmd\" and a built-in rebase?\n\n> 2008/6/7 Karl Hasselström :\n>\n> > What I think I'd like is the following:\n> >\n> > * Just one command, stg pull. stg rebase is removed.\n>\n> I still find \"rebase\" useful and use it in some situations when I\n> don't need a pull. As Jakub mentioned, maybe we could keep the\n> \"rebase\" functionality outside of the \"pull\" command (make it part\n> of Stack with a corresponding Branch.rebase?) and have \"rebase\" use\n> it.\n\nYes. We could have \"stg rebase\" == \"stg pull --rebase --no-fetch\".\n\n> > 2. Depending on the configuration (overridable by the\n> > --fast-forward, --rebase, and --merge options), one of these\n> > three things happen:\n>\n> But \"pull\" always suggests fetching something. Adding \"--rebase\"\n> would mean that it doesn't fetch. Shouldn't we leave this\n> functionality to \"rebase\" only?\n\nThese two things are orthogonal:\n\n 1. Whether and how to update the branch we're pulling from\n (fetching).\n\n 2. How to do the actual pulling (rebase, fast-forward, or merge).\n\nI envision (1) being controlled by the branch config (and overridable\nwith a --no-fetch option or something), and (2) being controlled by\nanother part of the branch config (and overridable with\n--fast-forward, --merge, and --rebase).\n\n> > 1. We pop all patches, fast-forward to the new base, and\n> > push them back. If it's not a fast-forward, we error\n> > out.\n> >\n> > 2. We pop all patches, reset to the new base, and push\n> > them back.\n> >\n> > 3. We pop all patches, merge with the other branch, then\n> > push the patches back.\n>\n> These are OK, with the comment on have rebase functionality in\n> \"rebase\" only.\n\nWhy? I don't see the difference between rebase and the other two that\nwould motivate such a separation.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"79362","messageId":"b0943d9e0806100843j28bb3353y5889a50712377959@mail.gmail.com","threadId":"13852","inReplyTo":"20080610104244.GC30119@diana.vm.bytemark.co.uk","subject":"Re: stg pull/rebase","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2008-06-10T15:43:27Z","receivedAt":"2008-06-10T15:43:27Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"2008/6/10 Karl Hasselström :\n> On 2008-06-10 11:02:18 +0100, Catalin Marinas wrote:\n>\n>> However, I found some these policies useful. For example, I just do\n>> a \"stg pull\" from a Subversion repository with the config below:\n>>\n>> [stgit]\n>> pull-policy = fetch-rebase\n>> fetchcmd = git svn fetch\n>> rebasecmd = git svn rebase\n>\n> Looks useful.\n>\n> But what exactly is \"rebasecmd\" useful for, when you already have\n> \"fetchcmd\" and a built-in rebase?\n\nIn case the built-in rebase is not enough. Can you use \"git svn fetch\"\nfollowed by plain \"git rebase\"? There are some comments in git-svn.txt\nthat recommend to use \"git svn rebase\" to preserve linear history.\n\n>> 2008/6/7 Karl Hasselström :\n>> > 2. Depending on the configuration (overridable by the\n>> > --fast-forward, --rebase, and --merge options), one of these\n>> > three things happen:\n>>\n>> But \"pull\" always suggests fetching something. Adding \"--rebase\"\n>> would mean that it doesn't fetch. Shouldn't we leave this\n>> functionality to \"rebase\" only?\n>\n> These two things are orthogonal:\n>\n> 1. Whether and how to update the branch we're pulling from\n> (fetching).\n>\n> 2. How to do the actual pulling (rebase, fast-forward, or merge).\n\nI think it's more of an language interpretation issue (I'm not a\nnative English speaker). I see the \"pull\" action as pulling (can't\nfind meaningful synonyms) remote changes into the current branch (i.e.\nfetch + merge). I think you see it as pulling the current stack onto a\nnew base (i.e. rebase).\n\n> I envision (1) being controlled by the branch config (and overridable\n> with a --no-fetch option or something), and (2) being controlled by\n> another part of the branch config (and overridable with\n> --fast-forward, --merge, and --rebase).\n\nOK.\n\n>> > 1. We pop all patches, fast-forward to the new base, and\n>> > push them back. If it's not a fast-forward, we error\n>> > out.\n>> >\n>> > 2. We pop all patches, reset to the new base, and push\n>> > them back.\n>> >\n>> > 3. We pop all patches, merge with the other branch, then\n>> > push the patches back.\n>>\n>> These are OK, with the comment on have rebase functionality in\n>> \"rebase\" only.\n>\n> Why? I don't see the difference between rebase and the other two that\n> would motivate such a separation.\n\nSee my interpretation of the word \"pull\". I can change my mind, no\nproblem, but it would be interesting to see what a native English\nspeaker says (though you are probably closer to English than me :-)).\n\n-- \nCatalin\n"},{"id":"79433","messageId":"20080611061110.GA15034@diana.vm.bytemark.co.uk","threadId":"13852","inReplyTo":"b0943d9e0806100843j28bb3353y5889a50712377959@mail.gmail.com","subject":"Re: stg pull/rebase","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-06-11T06:11:10Z","receivedAt":"2008-06-11T06:11:10Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-06-10 16:43:27 +0100, Catalin Marinas wrote:\n\n> 2008/6/10 Karl Hasselström :\n>\n> > On 2008-06-10 11:02:18 +0100, Catalin Marinas wrote:\n> >\n> > > However, I found some these policies useful. For example, I just\n> > > do a \"stg pull\" from a Subversion repository with the config\n> > > below:\n> > >\n> > > [stgit]\n> > > pull-policy = fetch-rebase\n> > > fetchcmd = git svn fetch\n> > > rebasecmd = git svn rebase\n> >\n> > Looks useful.\n> >\n> > But what exactly is \"rebasecmd\" useful for, when you already have\n> > \"fetchcmd\" and a built-in rebase?\n>\n> In case the built-in rebase is not enough. Can you use \"git svn\n> fetch\" followed by plain \"git rebase\"? There are some comments in\n> git-svn.txt that recommend to use \"git svn rebase\" to preserve\n> linear history.\n\nYou most definitely can. I've been doing so daily for more than a\nyear:\n\n $ git svn fetch -q\n $ stg rebase -m svn/branch\n\nI _think_ what git svn rebase does is look at the git-svn commit\nmetadata to determine how many commits to rebase. But stg already has\nthis information, so we don't need it. (I haven't actually looked into\nexactly what git svn rebase does, so it might turn out it's doing\nsomething else too, but I can't think of anything that would be\nnecessary. As I said, I've been using this workflow for a long time,\nand it works.)\n\nThe _advantage_ of having fetch be the only external command (besides\nreducing complexity) is that we can make it all one single StGit\ntransaction (since the fetch runs to completion before the transaction\nstarts). This means that we don't have to touch files unnecessarily,\nwhich means less recompilation.\n\n> > > But \"pull\" always suggests fetching something. Adding \"--rebase\"\n> > > would mean that it doesn't fetch. Shouldn't we leave this\n> > > functionality to \"rebase\" only?\n> >\n> > These two things are orthogonal:\n> >\n> > 1. Whether and how to update the branch we're pulling from\n> > (fetching).\n> >\n> > 2. How to do the actual pulling (rebase, fast-forward, or merge).\n>\n> I think it's more of an language interpretation issue (I'm not a\n> native English speaker). I see the \"pull\" action as pulling (can't\n> find meaningful synonyms) remote changes into the current branch\n> (i.e. fetch + merge). I think you see it as pulling the current\n> stack onto a new base (i.e. rebase).\n\nWell, the reason I proposed to keep \"stg pull\" rather than \"stg\nrebase\" is that I agree with you that \"pull\" means \"fetch _and_\nintegrate\". (Let's try a new term; \"integrate\" means either \"merge\",\n\"fast-forward\", or \"rebase\" (none of which implies any fetching, of\ncourse).) This is how I imagine it working:\n\n stg pull\n\n Do a default fetch (that is, fetch according to the branch\n config), followed by a default integrate.\n\n stg pull --no-fetch\n\n Just a default integrate, no fetch.\n\n stg pull --fetch-only\n\n Just a default fetch, no integrate.\n\n stg pull --fast-forward\n\n Default fetch, followed by a \"fast-forward\" integrate.\n\n stg pull --rebase\n\n Default fetch, followed by a \"rebase\" integrate.\n\n stg pull --merge\n\n Default fetch, followed by a \"merge\" integrate.\n\nAny of --no-fetch/--fetch-only can be combined with any of\n--fast-forward/--rebase/--merge.\n\nIf stg pull is given a committish argument, this automatically means\n--no-fetch, and causes it to integrate with that committish rather\nthan the branch specified in the config. We might want to allow other\nkinds of arguments as well, I don't know.\n\nAnd of course,\n\n stg rebase [committish]\n\n The same as \"stg pull --no-fetch --rebase [committish]\"; that is,\n no fetch, just rebase.\n\n> > > These are OK, with the comment on have rebase functionality in\n> > > \"rebase\" only.\n> >\n> > Why? I don't see the difference between rebase and the other two\n> > that would motivate such a separation.\n>\n> See my interpretation of the word \"pull\". I can change my mind, no\n> problem, but it would be interesting to see what a native English\n> speaker says (though you are probably closer to English than me\n> :-)).\n\nMph, I don't know about me being \"closer\". I thought you were the one\nliving in the UK? ;-)\n\nRegardless, I don't think we're actually in disagreement -- as I\nunderstand it, we both think that pull = fetch + integrate. And\n\"rebase\" is one possible value of \"integrate\". (Holler if you disagree\nwith either of the views I've attributed to you.)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"79464","messageId":"b0943d9e0806111000s4faecfa8o4e4042245c6ff2ba@mail.gmail.com","threadId":"13852","inReplyTo":"20080611061110.GA15034@diana.vm.bytemark.co.uk","subject":"Re: stg pull/rebase","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2008-06-11T17:00:25Z","receivedAt":"2008-06-11T17:00:25Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"2008/6/11 Karl Hasselström :\n> On 2008-06-10 16:43:27 +0100, Catalin Marinas wrote:\n>\n>> 2008/6/10 Karl Hasselström :\n>> > But what exactly is \"rebasecmd\" useful for, when you already have\n>> > \"fetchcmd\" and a built-in rebase?\n>>\n>> In case the built-in rebase is not enough. Can you use \"git svn\n>> fetch\" followed by plain \"git rebase\"? There are some comments in\n>> git-svn.txt that recommend to use \"git svn rebase\" to preserve\n>> linear history.\n>\n> You most definitely can. I've been doing so daily for more than a\n> year:\n>\n> $ git svn fetch -q\n> $ stg rebase -m svn/branch\n\nMaybe, I haven't tried (I just followed the git-svn documentation). Is\nthe imported svn history linear? If it works, I no longer have a need\nfor a rebasecmd option.\n\n> The _advantage_ of having fetch be the only external command (besides\n> reducing complexity) is that we can make it all one single StGit\n> transaction (since the fetch runs to completion before the transaction\n> starts). This means that we don't have to touch files unnecessarily,\n> which means less recompilation.\n\nThat's a good reason.\n\n>> I think it's more of an language interpretation issue (I'm not a\n>> native English speaker). I see the \"pull\" action as pulling (can't\n>> find meaningful synonyms) remote changes into the current branch\n>> (i.e. fetch + merge). I think you see it as pulling the current\n>> stack onto a new base (i.e. rebase).\n>\n> Well, the reason I proposed to keep \"stg pull\" rather than \"stg\n> rebase\" is that I agree with you that \"pull\" means \"fetch _and_\n> integrate\". (Let's try a new term; \"integrate\" means either \"merge\",\n> \"fast-forward\", or \"rebase\" (none of which implies any fetching, of\n> course).) This is how I imagine it working:\n[...]\n> Any of --no-fetch/--fetch-only can be combined with any of\n> --fast-forward/--rebase/--merge.\n>\n> If stg pull is given a committish argument, this automatically means\n> --no-fetch, and causes it to integrate with that committish rather\n> than the branch specified in the config. We might want to allow other\n> kinds of arguments as well, I don't know.\n>\n> And of course,\n>\n> stg rebase [committish]\n>\n> The same as \"stg pull --no-fetch --rebase [committish]\"; that is,\n> no fetch, just rebase.\n\nI'm OK, as long as we keep a \"rebase\" alias :-)\n\n>> See my interpretation of the word \"pull\". I can change my mind, no\n>> problem, but it would be interesting to see what a native English\n>> speaker says (though you are probably closer to English than me\n>> :-)).\n>\n> Mph, I don't know about me being \"closer\". I thought you were the one\n> living in the UK? ;-)\n\nI was more thinking about the native language roots (Germanic vs Latin\nin my case, I've only lived in the UK for 7 years) :-)\n\n> Regardless, I don't think we're actually in disagreement -- as I\n> understand it, we both think that pull = fetch + integrate. And\n> \"rebase\" is one possible value of \"integrate\".\n\nI think the disagreement is that I consider \"fetch\" in the above\nequality to be mandatory. But I think your proposal is OK.\n\n-- \nCatalin\n"},{"id":"79483","messageId":"20080611190732.GA23670@diana.vm.bytemark.co.uk","threadId":"13852","inReplyTo":"b0943d9e0806111000s4faecfa8o4e4042245c6ff2ba@mail.gmail.com","subject":"Re: stg pull/rebase","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-06-11T19:07:32Z","receivedAt":"2008-06-11T19:07:32Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-06-11 18:00:25 +0100, Catalin Marinas wrote:\n\n> 2008/6/11 Karl Hasselström :\n>\n> > On 2008-06-10 16:43:27 +0100, Catalin Marinas wrote:\n> >\n> > > 2008/6/10 Karl Hasselström :\n> > >\n> > > > But what exactly is \"rebasecmd\" useful for, when you already\n> > > > have \"fetchcmd\" and a built-in rebase?\n> > >\n> > > In case the built-in rebase is not enough. Can you use \"git svn\n> > > fetch\" followed by plain \"git rebase\"? There are some comments\n> > > in git-svn.txt that recommend to use \"git svn rebase\" to\n> > > preserve linear history.\n> >\n> > You most definitely can. I've been doing so daily for more than a\n> > year:\n> >\n> > $ git svn fetch -q\n> > $ stg rebase -m svn/branch\n>\n> Maybe, I haven't tried (I just followed the git-svn documentation).\n> Is the imported svn history linear?\n\nYes, it's linear. (Can git-svn do anything else?)\n\n> If it works, I no longer have a need for a rebasecmd option.\n\nAs I said, it works for me. And I can't really think of a case where\nit wouldn't work. Try it and see!\n\n> > And of course,\n> >\n> > stg rebase [committish]\n> >\n> > The same as \"stg pull --no-fetch --rebase [committish]\"; that\n> > is, no fetch, just rebase.\n>\n> I'm OK, as long as we keep a \"rebase\" alias :-)\n\nI guess you and Jakub have me cornered here. ;-)\n\n> > > See my interpretation of the word \"pull\". I can change my mind,\n> > > no problem, but it would be interesting to see what a native\n> > > English speaker says (though you are probably closer to English\n> > > than me :-)).\n> >\n> > Mph, I don't know about me being \"closer\". I thought you were the\n> > one living in the UK? ;-)\n>\n> I was more thinking about the native language roots (Germanic vs\n> Latin in my case, I've only lived in the UK for 7 years) :-)\n\nEnglish is too far from Swedish in this case. My guideline in these\nmatters is my overconfidence in my own English skills. (And in this\nparticular case, having followed a mailing list where every month a\nnew unsuspecting user is taught that pull = fetch + merge.)\n\n> > Regardless, I don't think we're actually in disagreement -- as I\n> > understand it, we both think that pull = fetch + integrate. And\n> > \"rebase\" is one possible value of \"integrate\".\n>\n> I think the disagreement is that I consider \"fetch\" in the above\n> equality to be mandatory.\n\nWell, I too consider \"pull\" to imply \"fetch\", so I don't see a\ndisagreement. I only called it \"stg pull --no-fetch\" instead of \"stg\nintegrate\" or whatever because (1) users will have an easier time\nfinding it that way, and (2) we have too many stg subcommands already.\n\n> But I think your proposal is OK.\n\nYay!\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"}]}