{"thread":{"id":"6778","subject":"StGIT discards local commits on \"stg pull\"","startedAt":"2007-02-12T07:26:25Z","lastAt":"2007-02-20T18:55:32Z","messageCount":12,"participants":["Pavel Roskin","Catalin Marinas","Yann Dirson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"34263","messageId":"20070212022625.rvyyo0kc0wowgogc@webmail.spamcop.net","threadId":"6778","inReplyTo":null,"subject":"StGIT discards local commits on \"stg pull\"","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-02-12T07:26:25Z","receivedAt":"2007-02-12T07:26:25Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nI have been bitten by a strange bug/feature of StGIT, and it looks like it's not\nonly counterintuitive, but also inconsistent with git.\n\nI have a repository available over ssh and I push to it from several places. \nSometimes I make a commit and forget to push it. Then I run \"stg pull\" to make\nsure my repository is up to date.\n\nThe result is that the repository is rebased back to the last remote commit. \nIt's very easy to miss. There is no warning. Everything looks just like an\nupdate from the remote.\n\nThe example below shows that git-pull keeps my commit, but \"stg pull\" discards\nit by rebasing back to the remote ID.\n\nMy .gitconfig doesn't override \"stg pull\" behavior; it merely sets my name and\nmail aliases.\n\n[proski@dl stgit-test]$ stg id\nebc429e7b7e596a12e8255fadc397123893cec73\n[proski@dl stgit-test]$ echo \"test change\" >README\n[proski@dl stgit-test]$ git-commit -m \"test commit\" README\nCreated commit 468861a2a1530f3bf98108e69632b3059e4ca0ce\n 1 files changed, 1 insertions(+), 14 deletions(-)\n[proski@dl stgit-test]$ git-pull\nFetching refs/heads/master from http://homepage.ntlworld.com/cmarinas/stgit.git\nusing http\nFetching refs/heads/stable from http://homepage.ntlworld.com/cmarinas/stgit.git\nusing http\nAlready up-to-date.\n[proski@dl stgit-test]$ stg id\n468861a2a1530f3bf98108e69632b3059e4ca0ce\n[proski@dl stgit-test]$ stg pull\nChecking for changes in the working directory... done\nPulling from \"origin\"...\nFetching refs/heads/master from http://homepage.ntlworld.com/cmarinas/stgit.git\nusing http\nFetching refs/heads/stable from http://homepage.ntlworld.com/cmarinas/stgit.git\nusing http\nrebasing to \"ebc429e7b7e596a12e8255fadc397123893cec73\"...\ndone\nNo patches applied\n[proski@dl stgit-test]$ stg id\nebc429e7b7e596a12e8255fadc397123893cec73\n[proski@dl stgit-test]$\n\n--\nRegards,\nPavel Roskin\n"},{"id":"34268","messageId":"b0943d9e0702120131r528fb29ete143b8ce5a0a99e9@mail.gmail.com","threadId":"6778","inReplyTo":"20070212022625.rvyyo0kc0wowgogc@webmail.spamcop.net","subject":"Re: StGIT discards local commits on \"stg pull\"","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-02-12T09:31:28Z","receivedAt":"2007-02-12T09:31:28Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 12/02/07, Pavel Roskin wrote:\n> I have been bitten by a strange bug/feature of StGIT, and it looks like\n> it's not only counterintuitive, but also inconsistent with git.\n>\n> I have a repository available over ssh and I push to it from several\n> places. Sometimes I make a commit and forget to push it. Then I run \"stg\n> pull\" to make sure my repository is up to date.\n>\n> The result is that the repository is rebased back to the last remote\n> commit. It's very easy to miss. There is no warning. Everything looks\n> just like an update from the remote.\n>\n> The example below shows that git-pull keeps my commit, but \"stg pull\"\n> discards it by rebasing back to the remote ID.\n\nI think this is a \"feature\" but we should've probably leave the\noriginal behaviour as the default. Maybe we should also have this\nper-branch rather than per-repository.\n\nIn StGIT 0.12, git-fetch is used by default rather than git-pull and\nStGIT performs the rebasing. We had some discussions on whether this\nwould break existing workflows and we thought it wouldn't (I don't\nusually mix git-commit with stg commands).\n\nThe solution would be to define the following in your gitconfig file\n(either ~/.gitconfig or .git/config; a full example in StGIT's\nexamples/gitconfig):\n\n[stgit]\n\tpullcmd = git-pull\n\tpull-does-rebase = no\n\nThe last line would tell StGIT not to do the rebasing and let git-pull\nhandle it.\n\nI agree that for the rebasing case, we should have some warning if\nfast-forwarding of the stack's base is not possible so that you could\nrun 'stg uncommit'.\n\n-- \nCatalin\n"},{"id":"34316","messageId":"20070212202634.GX4266@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6778","inReplyTo":"b0943d9e0702120131r528fb29ete143b8ce5a0a99e9@mail.gmail.com","subject":"Re: StGIT discards local commits on \"stg pull\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-02-12T20:26:34Z","receivedAt":"2007-02-12T20:26:34Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, Feb 12, 2007 at 09:31:28AM +0000, Catalin Marinas wrote:\n> On 12/02/07, Pavel Roskin wrote:\n> >I have been bitten by a strange bug/feature of StGIT, and it looks like\n> >it's not only counterintuitive, but also inconsistent with git.\n> >\n> >I have a repository available over ssh and I push to it from several\n> >places. Sometimes I make a commit and forget to push it. Then I run \"stg\n> >pull\" to make sure my repository is up to date.\n> >\n> >The result is that the repository is rebased back to the last remote\n> >commit. It's very easy to miss. There is no warning. Everything looks\n> >just like an update from the remote.\n> >\n> >The example below shows that git-pull keeps my commit, but \"stg pull\"\n> >discards it by rebasing back to the remote ID.\n> \n> I think this is a \"feature\"\n\nNo, I agree it's a bug. Rebasing after a fetch should allow this\nworkflow to work as well. If the parent branch is not a rewinding\none, we should ensure there is nothing lost. And even for rewinding\nbranches, we should probably keep track of the existence of commits,\nso we can warn and nothing gets lost without knowing.\n\nThat makes me think that in most cases, an \"stg commit\" is done to be\npushed to a remote repo, as symetric operation to \"stg pull\".\nProbably we could add support for this sort of operation (similar to\n\"stg-cvs commit\" from my script).\n\n\n> but we should've probably leave the\n> original behaviour as the default. Maybe we should also have this\n> per-branch rather than per-repository.\n\nRight, having it per-branch would allow, eg. to declare something like\ngit-svn as the way to pull from a given branch, while using different\nbackends for other branches.\n\n\n> I agree that for the rebasing case, we should have some warning if\n> fast-forwarding of the stack's base is not possible so that you could\n> run 'stg uncommit'.\n\nRight. \"rebase --undo\" could help too.\n\nbest regards,\n-- \nYann.\n"},{"id":"34323","messageId":"20070212214704.GS5362@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6778","inReplyTo":"20070212202634.GX4266@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: StGIT discards local commits on \"stg pull\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-02-12T21:47:04Z","receivedAt":"2007-02-12T21:47:04Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, Feb 12, 2007 at 09:26:34PM +0100, Yann Dirson wrote:\n> On Mon, Feb 12, 2007 at 09:31:28AM +0000, Catalin Marinas wrote:\n> > On 12/02/07, Pavel Roskin wrote:\n> > >I have been bitten by a strange bug/feature of StGIT, and it looks like\n> > >it's not only counterintuitive, but also inconsistent with git.\n> > >\n> > >I have a repository available over ssh and I push to it from several\n> > >places. Sometimes I make a commit and forget to push it. Then I run \"stg\n> > >pull\" to make sure my repository is up to date.\n> > >\n> > >The result is that the repository is rebased back to the last remote\n> > >commit. It's very easy to miss. There is no warning. Everything looks\n> > >just like an update from the remote.\n> > >\n> > >The example below shows that git-pull keeps my commit, but \"stg pull\"\n> > >discards it by rebasing back to the remote ID.\n> > \n> > I think this is a \"feature\"\n> \n> No, I agree it's a bug. Rebasing after a fetch should allow this\n> workflow to work as well. If the parent branch is not a rewinding\n> one, we should ensure there is nothing lost. And even for rewinding\n> branches, we should probably keep track of the existence of commits,\n> so we can warn and nothing gets lost without knowing.\n\nThinking about it, detecting whether we're going to lose a commit is\njust checking *before pulling* whether the current base is reachable\nfrom the parent's current head.\n\nIn git-fetch-based workflows, proceeding further should be simply\nrefused. I'm not sure about the git-pull-based workflows; here is at\nleast one problem with git-pull I can think of:\n\nAFAICT, someone using git-pull would in this case get a merge commit,\nso under 0.11 (or with the compat settings outlined by Catalin) you\nshould now have your stack based on a merge commit, with as parents\nthe new parent-branch head and the commits you did not push yet, right ?\nSo how did you proceed from there using 0.11 ?\n\nI'd think you still want to push your patch into the parent repo, but\nthe situtation is cumbersome: it would have been far easier IMHO to\n\"stg pull\" first, in which case the fetch-and-rebase model is what you\nwanted, and then do a \"stg commit && git push\".\n\nThat makes me think that indeed we should have an stgit command doing\nprecisely this \"stg commit && git push\" (suggested in previous mail)\nas an atomic operation, rolling back the commit if the push failed\nbecause you were out of date.\n\n\nSince that looks like a pathological case, I suppose this may not be\nwhat you were trying to do. Can you please give more information if\nthat is the case ?\n\nBest regards,\n-- \nYann.\n"},{"id":"34346","messageId":"1171326011.2326.30.camel@dv","threadId":"6778","inReplyTo":"b0943d9e0702120131r528fb29ete143b8ce5a0a99e9@mail.gmail.com","subject":"Re: StGIT discards local commits on \"stg pull\"","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-02-13T00:20:11Z","receivedAt":"2007-02-13T00:20:11Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Mon, 2007-02-12 at 09:31 +0000, Catalin Marinas wrote:\n> On 12/02/07, Pavel Roskin wrote:\n\n> > The example below shows that git-pull keeps my commit, but \"stg pull\"\n> > discards it by rebasing back to the remote ID.\n> \n> I think this is a \"feature\" but we should've probably leave the\n> original behaviour as the default. Maybe we should also have this\n> per-branch rather than per-repository.\n\nI don't know the original motivation behind effectively reimplementing\n\"git pull\" in StGIT, but it's clear that the StGIT's own implementation\nneeds some polish.\n\nI think it's always wrong to lose local commits. I think StGIT should\nrefuse to rebase if a merge would be needed or the rebase would go back\nin history (in other words, if git-pull would not go to the remote\nrevision).\n\n> In StGIT 0.12, git-fetch is used by default rather than git-pull and\n> StGIT performs the rebasing. We had some discussions on whether this\n> would break existing workflows and we thought it wouldn't (I don't\n> usually mix git-commit with stg commands).\n\nMaybe such assumptions could be enforced? Perhaps we could consider\nbranch specialization. As it stands now, we can have branches where\nfast-forward is OK and branches where it's not OK.\n\nIf we look at it from the user standpoint, the branches could be\ndistinguished by the use model:\n\n1) Tracking branch: pull is OK, commit is not OK, push is not OK. All\ndevelopment is done in StGIT patches and sent to others.\n\n2) Development branch: commit is OK, push is OK, pull is OK but no\nmerges by default.\n\n3) Merge branch: pull is OK, even with automatic merge, commit is OK,\nmerge is OK.\n\nI'm not sure if this belongs to git or StGIT.\n\n> The solution would be to define the following in your gitconfig file\n> (either ~/.gitconfig or .git/config; a full example in StGIT's\n> examples/gitconfig):\n> \n> [stgit]\n> \tpullcmd = git-pull\n> \tpull-does-rebase = no\n> \n> The last line would tell StGIT not to do the rebasing and let git-pull\n> handle it.\n\nIt's actually my deliberate choice to subject myself to the pains of the\ndefault configuration. I don't want to live in backwards compatible\nenvironment until it rots away. I'll rather eat the dogfood we are\noffering to others :)\n\n> I agree that for the rebasing case, we should have some warning if\n> fast-forwarding of the stack's base is not possible so that you could\n> run 'stg uncommit'.\n\nSounds good to me.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"34478","messageId":"b0943d9e0702131448x360018b3w6d1790a84f201710@mail.gmail.com","threadId":"6778","inReplyTo":"1171326011.2326.30.camel@dv","subject":"Re: StGIT discards local commits on \"stg pull\"","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-02-13T22:48:11Z","receivedAt":"2007-02-13T22:48:11Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 13/02/07, Pavel Roskin wrote:\n> On Mon, 2007-02-12 at 09:31 +0000, Catalin Marinas wrote:\n> > On 12/02/07, Pavel Roskin wrote:\n>\n> > > The example below shows that git-pull keeps my commit, but \"stg pull\"\n> > > discards it by rebasing back to the remote ID.\n> >\n> > I think this is a \"feature\" but we should've probably leave the\n> > original behaviour as the default. Maybe we should also have this\n> > per-branch rather than per-repository.\n>\n> I don't know the original motivation behind effectively reimplementing\n> \"git pull\" in StGIT, but it's clear that the StGIT's own implementation\n> needs some polish.\n\nYann can describe the motivation better as he was the one pushing for\nit. It was mainly to allow different local branches to be based on\ndifferent remote branches. In the normal case, i.e. using only StGIT\ncommands, there shouldn't be any difference. As I said, the old\nbehaviour is still present and maybe we should do the new one\nper-branch.\n\n> I think it's always wrong to lose local commits. I think StGIT should\n> refuse to rebase if a merge would be needed or the rebase would go back\n> in history (in other words, if git-pull would not go to the remote\n> revision).\n\nYes, indeed.\n\n> If we look at it from the user standpoint, the branches could be\n> distinguished by the use model:\n>\n> 1) Tracking branch: pull is OK, commit is not OK, push is not OK. All\n> development is done in StGIT patches and sent to others.\n>\n> 2) Development branch: commit is OK, push is OK, pull is OK but no\n> merges by default.\n>\n> 3) Merge branch: pull is OK, even with automatic merge, commit is OK,\n> merge is OK.\n\nI probably have another situation - a branch managed partially with\nStGIT but GIT commits (or 'stg commit') used and pulling would lead to\na merge of the base, followed by patch pushing. This would work if we\nuse git-pull rather than git-fetch.\n\n> > The solution would be to define the following in your gitconfig file\n> > (either ~/.gitconfig or .git/config; a full example in StGIT's\n> > examples/gitconfig):\n> >\n> > [stgit]\n> > pullcmd = git-pull\n> > pull-does-rebase = no\n> >\n> > The last line would tell StGIT not to do the rebasing and let git-pull\n> > handle it.\n>\n> It's actually my deliberate choice to subject myself to the pains of the\n> default configuration. I don't want to live in backwards compatible\n> environment until it rots away. I'll rather eat the dogfood we are\n> offering to others :)\n\nI don't consider this as a backward-compatibility feature. It simply\ntargets a different workflow and it would be even better if we have it\nper-branch. The default should be the current fetch+rebase (as the\nmost common case would be to use StGIT commands only) but with a\nwarning if stack base fast-forwarding is not possible.\n\n-- \nCatalin\n"},{"id":"35053","messageId":"20070219204723.GA4314@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6778","inReplyTo":"b0943d9e0702131448x360018b3w6d1790a84f201710@mail.gmail.com","subject":"Re: StGIT discards local commits on \"stg pull\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-02-19T20:47:23Z","receivedAt":"2007-02-19T20:47:23Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Tue, Feb 13, 2007 at 10:48:11PM +0000, Catalin Marinas wrote:\n> On 13/02/07, Pavel Roskin wrote:\n> >On Mon, 2007-02-12 at 09:31 +0000, Catalin Marinas wrote:\n> >> On 12/02/07, Pavel Roskin wrote:\n> >\n> >> > The example below shows that git-pull keeps my commit, but \"stg pull\"\n> >> > discards it by rebasing back to the remote ID.\n> >>\n> >> I think this is a \"feature\" but we should've probably leave the\n> >> original behaviour as the default. Maybe we should also have this\n> >> per-branch rather than per-repository.\n> >\n> >I don't know the original motivation behind effectively reimplementing\n> >\"git pull\" in StGIT, but it's clear that the StGIT's own implementation\n> >needs some polish.\n\nThe primary motivation was to allow some sort of distributed handling\nof a stack. That is, I publish an stgit-managed branch, you \"stg\nclone\" it, you create your own patches on top of that, and when I\nrefresh my stack, you can just \"stg pull\" it as you would do if my\npublished work was a standard non-rewinding git branch.\n\n\n> >I think it's always wrong to lose local commits. I think StGIT should\n> >refuse to rebase if a merge would be needed\n\nRight, we should make it so losing local commits cannot be done by\nerror. However, we cannot rely on the branch topology at the time\nwe're rebasing. Consider those 2 use cases:\n\n- my stack forks off a non-rewinding branch, and I \"stg commit\" part\nof it, then \"stg pull\"\n\n- my stack forks off a rewinding branch, and I use \"git fetch\" to look\nat what's new upstream, then I decide it's a good time to rebase, and\nrun \"stg pull\" (or preferably \"stg rebase\" to avoid fetching more\nrecent commits by error)\n\nIn the 2 cases \"git pull\" would do a merge. One crucial thing\ndistinguishes the 2 cases, is that in the 1st case we have \"manually\"\nmessed with the stack base. By \"manually\", I mean we changed the\nstack base by other means than pulling/rebasing, but this notion\npossibly needs some tuning. \"stg commit\" is an example, \"stg\nuncommit\" is another, and both would cause \"git pull\" to do a merge\n*because rebasing would not be what you want*, whereas in the\nrewinding-branch use-case *what you is precisely rebasing*.\n\nWhat we could do then, is having \"rebase\" and \"pull\" record an\norig-base ref as a \"backup copy\" of the the new base, and first refuse\nto do the job (unless --force'd) if the base does not match its backup\n(that is, if the user used \"commit\" or \"uncommit\").\n\n> >or the rebase would go back in history (in other words, if\n> >git-pull would not go to the remote revision).\n\nI'm less sure about the use-case you're trying to address here. Could\nyou please give more details ? The only case I can think of would be\nthat of a rewinding branch that would have been just that, rewinded,\nso it should be handled differently than when any new commit would\nexist on top of this ancestor commit.\n\n\n> >If we look at it from the user standpoint, the branches could be\n> >distinguished by the use model:\n> >\n> >1) Tracking branch: pull is OK, commit is not OK, push is not OK. All\n> >development is done in StGIT patches and sent to others.\n> >\n> >2) Development branch: commit is OK, push is OK, pull is OK but no\n> >merges by default.\n\nRight, those ones are probably the most used.\n\n> >3) Merge branch: pull is OK, even with automatic merge, commit is OK,\n> >merge is OK.\n\nThis one I'm not sure to understand well. Could you please describe\nit in more details, perhaps in terms of the relation with other repos,\nand of the most distinctive local operations ?\n\n> I probably have another situation - a branch managed partially with\n> StGIT but GIT commits (or 'stg commit') used and pulling would lead to\n> a merge of the base, followed by patch pushing. This would work if we\n> use git-pull rather than git-fetch.\n\nYou mean, a branch to which possibly several devs would commit (or to\nwhich you want to commit multiple topic branches yourself), and where\nyou want to keep track of merges between these branches (as opposed to\nrebasing), while still using stgit locally ?\n\n\n> >> The solution would be to define the following in your gitconfig file\n> >> (either ~/.gitconfig or .git/config; a full example in StGIT's\n> >> examples/gitconfig):\n> >>\n> >> [stgit]\n> >> pullcmd = git-pull\n> >> pull-does-rebase = no\n> >>\n> >> The last line would tell StGIT not to do the rebasing and let git-pull\n> >> handle it.\n> >\n> >It's actually my deliberate choice to subject myself to the pains of the\n> >default configuration. I don't want to live in backwards compatible\n> >environment until it rots away. I'll rather eat the dogfood we are\n> >offering to others :)\n> \n> I don't consider this as a backward-compatibility feature. It simply\n> targets a different workflow and it would be even better if we have it\n> per-branch. The default should be the current fetch+rebase (as the\n> most common case would be to use StGIT commands only) but with a\n> warning if stack base fast-forwarding is not possible.\n\nOne way to handle different workflows could be to define a particular\nworkflow with a set of settings such as pullcmd and pull-does-rebase.\nThat way, we could say eg. \"stg branch --workflow=\" to set the\nvars in one run.\n\nBest regards,\n-- \nYann.\n"},{"id":"35039","messageId":"b0943d9e0702191507m636348e7yab2a712925f9f55@mail.gmail.com","threadId":"6778","inReplyTo":"20070212214704.GS5362@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: StGIT discards local commits on \"stg pull\"","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-02-19T23:07:09Z","receivedAt":"2007-02-19T23:07:09Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 12/02/07, Yann Dirson wrote:\n> On Mon, Feb 12, 2007 at 09:26:34PM +0100, Yann Dirson wrote:\n> > No, I agree it's a bug. Rebasing after a fetch should allow this\n> > workflow to work as well. If the parent branch is not a rewinding\n> > one, we should ensure there is nothing lost. And even for rewinding\n> > branches, we should probably keep track of the existence of commits,\n> > so we can warn and nothing gets lost without knowing.\n>\n> Thinking about it, detecting whether we're going to lose a commit is\n> just checking *before pulling* whether the current base is reachable\n> from the parent's current head.\n\nThere is a potential problem with this approach - pulling/fetching\nfrom a tree which is always rebased (either managed with StGIT or\nsimply running git-rebase before publishing it) would report an error\nsince the old base is no longer reachable from the current head. In\nthis case, the current fetch+rebase behaviour would be desirable.\n\nI think the fail-safe solution would be to leave the old behaviour\n(i.e. git-pull and pull-does-rebase=no) and people that need to pull\nfrom branches like that described above would use the fetch+rebase\napproach. Ideally, we'll have this configurable per-branch (and could\nleave the global one as well if the most specific is not available,\nbut should default to git-pull).\n\nLet me know what you think so that I'll try to release a 0.12.1 update\n(I already have the simple patch for using git-pull by default if you\nare OK with this scenario).\n\nThanks.\n\n-- \nCatalin\n"},{"id":"35042","messageId":"1171927720.2257.41.camel@dv","threadId":"6778","inReplyTo":"b0943d9e0702191507m636348e7yab2a712925f9f55@mail.gmail.com","subject":"Re: StGIT discards local commits on \"stg pull\"","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-02-19T23:28:40Z","receivedAt":"2007-02-19T23:28:40Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Mon, 2007-02-19 at 23:07 +0000, Catalin Marinas wrote:\n> On 12/02/07, Yann Dirson wrote:\n> > On Mon, Feb 12, 2007 at 09:26:34PM +0100, Yann Dirson wrote:\n> > > No, I agree it's a bug. Rebasing after a fetch should allow this\n> > > workflow to work as well. If the parent branch is not a rewinding\n> > > one, we should ensure there is nothing lost. And even for rewinding\n> > > branches, we should probably keep track of the existence of commits,\n> > > so we can warn and nothing gets lost without knowing.\n> >\n> > Thinking about it, detecting whether we're going to lose a commit is\n> > just checking *before pulling* whether the current base is reachable\n> > from the parent's current head.\n> \n> There is a potential problem with this approach - pulling/fetching\n> from a tree which is always rebased (either managed with StGIT or\n> simply running git-rebase before publishing it) would report an error\n> since the old base is no longer reachable from the current head. In\n> this case, the current fetch+rebase behaviour would be desirable.\n\nOne possible workaround would be to report an error and do nothing if\nthe old head would become unreachable (it's possible that I'm missing\nsomething and that it was discussed to death already).\n\n> I think the fail-safe solution would be to leave the old behaviour\n> (i.e. git-pull and pull-does-rebase=no) and people that need to pull\n> from branches like that described above would use the fetch+rebase\n> approach. Ideally, we'll have this configurable per-branch (and could\n> leave the global one as well if the most specific is not available,\n> but should default to git-pull).\n\nBy the way, it would be great to reduce all complexity to \"one bit\" per\nbranch. If stgit.internal-pull (the name is subject to improvement) is\non, \"stgit pull\" calls git-fetch and does rebase. Otherwise, it calls\ngit-pull. No need to configure two variables per branch.\n\n> Let me know what you think so that I'll try to release a 0.12.1 update\n> (I already have the simple patch for using git-pull by default if you\n> are OK with this scenario).\n\nAny fix for the current behavior would be fine to me. Either restore\nthe old default or don't rebase if the old head becomes unreachable.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"35060","messageId":"20070219234425.GJ4248@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6778","inReplyTo":"b0943d9e0702191507m636348e7yab2a712925f9f55@mail.gmail.com","subject":"Re: StGIT discards local commits on \"stg pull\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-02-19T23:44:25Z","receivedAt":"2007-02-19T23:44:25Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, Feb 19, 2007 at 11:07:09PM +0000, Catalin Marinas wrote:\n> >Thinking about it, detecting whether we're going to lose a commit is\n> >just checking *before pulling* whether the current base is reachable\n> >from the parent's current head.\n> \n> There is a potential problem with this approach - pulling/fetching\n> from a tree which is always rebased (either managed with StGIT or\n> simply running git-rebase before publishing it) would report an error\n> since the old base is no longer reachable from the current head.\n\nRight - a better solution is highlighted in today's proposal (which I\nhave started to implement).\n\n> In this case, the current fetch+rebase behaviour would be desirable.\n>\n> I think the fail-safe solution would be to leave the old behaviour\n> (i.e. git-pull and pull-does-rebase=no) and people that need to pull\n> from branches like that described above would use the fetch+rebase\n> approach.\n\nWe could do this, but I only see this as a temporary measure to avoid\nunleashing the new behaviour onto unsuspicious users before we've\nironed out the final behaviour. I still think that the current\nbehaviour belongs to a very specific workflow which is not that\nexpected by most users.\n\n\n> Ideally, we'll have this configurable per-branch (and could\n> leave the global one as well if the most specific is not available,\n\nRight.\n\n> but should default to git-pull).\n>\n> Let me know what you think so that I'll try to release a 0.12.1 update\n> (I already have the simple patch for using git-pull by default if you\n> are OK with this scenario).\n\nSince it is important that users don't unknowingly loose commits, yes\nit is preferable to release 0.12.1 with the old behaviour. Let's take\nthe time to shake things more for 0.13, and we can reconsider this\nchoice by then.\n\nBest regards,\n-- \nYann.\n"},{"id":"35059","messageId":"20070220000059.GK4248@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6778","inReplyTo":"1171927720.2257.41.camel@dv","subject":"Re: StGIT discards local commits on \"stg pull\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-02-20T00:00:59Z","receivedAt":"2007-02-20T00:00:59Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, Feb 19, 2007 at 06:28:40PM -0500, Pavel Roskin wrote:\n> > I think the fail-safe solution would be to leave the old behaviour\n> > (i.e. git-pull and pull-does-rebase=no) and people that need to pull\n> > from branches like that described above would use the fetch+rebase\n> > approach. Ideally, we'll have this configurable per-branch (and could\n> > leave the global one as well if the most specific is not available,\n> > but should default to git-pull).\n> \n> By the way, it would be great to reduce all complexity to \"one bit\" per\n> branch. If stgit.internal-pull (the name is subject to improvement) is\n> on, \"stgit pull\" calls git-fetch and does rebase. Otherwise, it calls\n> git-pull. No need to configure two variables per branch.\n\nBeing able to specify the command to use makes it possible to hook to\nother SCM's (eg. using git-cvsimport, git-svn or similar).\n\nI'll try to adapt by stg-cvs script to fit into this model some day\n(indeed, \"pullcmd = stg-cvs fetch\" may indeed already work).\n\nBest regards,\n-- \nYann.\n"},{"id":"35135","messageId":"20070220185532.GA4149@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6778","inReplyTo":"20070220000059.GK4248@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: StGIT discards local commits on \"stg pull\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-02-20T18:55:32Z","receivedAt":"2007-02-20T18:55:32Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Tue, Feb 20, 2007 at 01:00:59AM +0100, Yann Dirson wrote:\n> On Mon, Feb 19, 2007 at 06:28:40PM -0500, Pavel Roskin wrote:\n> > > I think the fail-safe solution would be to leave the old behaviour\n> > > (i.e. git-pull and pull-does-rebase=no) and people that need to pull\n> > > from branches like that described above would use the fetch+rebase\n> > > approach. Ideally, we'll have this configurable per-branch (and could\n> > > leave the global one as well if the most specific is not available,\n> > > but should default to git-pull).\n> > \n> > By the way, it would be great to reduce all complexity to \"one bit\" per\n> > branch. If stgit.internal-pull (the name is subject to improvement) is\n> > on, \"stgit pull\" calls git-fetch and does rebase. Otherwise, it calls\n> > git-pull. No need to configure two variables per branch.\n> \n> Being able to specify the command to use makes it possible to hook to\n> other SCM's (eg. using git-cvsimport, git-svn or similar).\n\nThinking twice, we could make things even better :)\n\nLet's acknowledge that we have several ways of pulling, by getting rid\nof the awkward 'stgit.pull-does-rebase'. Instead we could use a new\n\"pull-policy\" setting, with possible values \"pull\" and \"fetch-rebase\"\nto match the 2 currently-available behaviours. Then according to the\npull-policy, \"stg pull\" would use \"pullcmd\" or a new \"fetchcmd\"\nsetting, thus removing the requirement to mess with pullcmd in the\ncommon case.\n\nAll of \"pull-policy\", \"pullcmd\", and \"fetchcmd\" would have a\nper-branch and a global setting (stgit. and\nbranch.*.stgit.).\n\nWe could also introduce a 3rd \"rebase\" policy, to support local parent\nbranches better.\n\nBest regards,\n-- \nYann.\n"}]}