{"thread":{"id":"11028","subject":"Re: What's cooking in git.git (topics)","startedAt":"2007-11-27T06:21:44Z","lastAt":"2007-11-29T17:47:58Z","messageCount":22,"participants":["しらいしななこ","Johannes Schindelin","Andreas Ericsson","Nicolas Pitre","J. Bruce Fields","Junio C Hamano","Johan Herland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"61032","messageId":"200711270622.lAR6MFXQ010010@mi0.bluebottle.com","threadId":"11028","inReplyTo":null,"subject":"Re: What's cooking in git.git (topics)","fromName":"しらいしななこ","fromEmail":"nanako3@bluebottle.com","sentAt":"2007-11-27T06:21:44Z","receivedAt":"2007-11-27T06:21:44Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Andreas Ericsson :\n\n> \"git pull --rebase\" already has an implementation. Dscho cooked one up\n> which I've been using since then. It works nicely.\n\nWhat is the reason that the option was not added to the official git? Was it coded poorly, buggy or were there some other issues?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n\n----------------------------------------------------------------------\nFind out how you can get spam free email.\nhttp://www.bluebottle.com/tag/3\n"},{"id":"61047","messageId":"Pine.LNX.4.64.0711271109130.27959@racer.site","threadId":"11028","inReplyTo":"200711270622.lAR6MFXQ010010@mi0.bluebottle.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-27T11:12:45Z","receivedAt":"2007-11-27T11:12:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Nov 2007, しらいしななこ wrote:\n\n> Quoting Andreas Ericsson :\n> \n> > \"git pull --rebase\" already has an implementation. Dscho cooked one up\n> > which I've been using since then. It works nicely.\n> \n> What is the reason that the option was not added to the official git? \n> Was it coded poorly, buggy or were there some other issues?\n\nIt is very well possible that it was coded poorly ;-)\n\nThe main reason, I believe, was that some old-timers who know the \nimplications said that it would encourage a wrong workflow. One thing \nthat could go possibly wrong, for example, is to rebase commits that you \nalready published.\n\nSo AFAICT it was deemed not only giving people rope, but making that rope \nlook like a necklace to them.\n\nCiao,\nDscho\n"},{"id":"61070","messageId":"474C1F80.5060404@op5.se","threadId":"11028","inReplyTo":"Pine.LNX.4.64.0711271109130.27959@racer.site","subject":"Re: What's cooking in git.git (topics)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-27T13:45:36Z","receivedAt":"2007-11-27T13:45:36Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 27 Nov 2007, しらいしななこ wrote:\n> \n>> Quoting Andreas Ericsson :\n>>\n>>> \"git pull --rebase\" already has an implementation. Dscho cooked one up\n>>> which I've been using since then. It works nicely.\n>> What is the reason that the option was not added to the official git? \n>> Was it coded poorly, buggy or were there some other issues?\n> \n> It is very well possible that it was coded poorly ;-)\n> \n> The main reason, I believe, was that some old-timers who know the \n> implications said that it would encourage a wrong workflow.\n\n\nIf by \"wrong\", those old-timers meant \"a workflow not commonly used\nin a published one-pushes-many-pulls repository\", I certainly agree.\n\n\n> One thing \n> that could go possibly wrong, for example, is to rebase commits that you \n> already published.\n> \n\nFor the vast majority of git users, that's a non-issue as \"published\" is\nusually defined as \"pushed to the publicly advertised watering hole\".\n\nYes, I'm aware that git is distributed. That doesn't mean that it's not\nconvenient to have one single place where all code meant to be released\neventually ends up.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"61072","messageId":"Pine.LNX.4.64.0711271352050.27959@racer.site","threadId":"11028","inReplyTo":"474C1F80.5060404@op5.se","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-27T13:54:17Z","receivedAt":"2007-11-27T13:54:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Nov 2007, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> \n> > One thing that could go possibly wrong, for example, is to rebase \n> > commits that you already published.\n> \n> For the vast majority of git users, that's a non-issue as \"published\" is \n> usually defined as \"pushed to the publicly advertised watering hole\".\n\nNo. This is only the \"vast majority of git users told by their peers to \nuse a central repository\".\n\nJust because you use git like cvs does not mean that you \"use git\".\n\n> Yes, I'm aware that git is distributed. That doesn't mean that it's not \n> convenient to have one single place where all code meant to be released \n> eventually ends up.\n\nIt may be convenient for you. I do not like it. Yes, I even made the \nmistake with msysGit. In the end, it would have been much more \nintelligent to set up a repository which others would have had to fork \nfrom.\n\nCiao,\nDscho\n"},{"id":"61078","messageId":"alpine.LFD.0.99999.0711270917580.9605@xanadu.home","threadId":"11028","inReplyTo":"Pine.LNX.4.64.0711271109130.27959@racer.site","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-27T14:29:21Z","receivedAt":"2007-11-27T14:29:21Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 27 Nov 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Tue, 27 Nov 2007, しらいしななこ wrote:\n> \n> > Was it coded poorly, buggy or were there some other issues?\n> \n> It is very well possible that it was coded poorly ;-)\n> \n> The main reason, I believe, was that some old-timers who know the \n> implications said that it would encourage a wrong workflow. One thing \n> that could go possibly wrong, for example, is to rebase commits that you \n> already published.\n\nBeing much more involved in the maintenance of a published Git tree \nlately, I must disagree with the \"wrong workflow\" statement. Until the \nstuff I maintain is finally merged upstream, I have to constantly \namend/replace/fold/split random commits in my repo to follow the review \ncycles involved. yet I have to publish the result to let others base \ntheir work on top of my latest tree. A fetch+rebase is the only option \nfor those following my tree, and I made it clear that they have to \nrebase after a fetch because I constantly rebase commits that I have \nalready published myself.\n\nAnd in this case, constant rebasing is a perfectly fine work flow to me. \nOtherwise I might just use Git as a glorified tarball downloader and use \nquilt on top, but this is somehow not as appealing.\n\n\nNicolas\n"},{"id":"61085","messageId":"20071127150829.GB3853@fieldses.org","threadId":"11028","inReplyTo":"alpine.LFD.0.99999.0711270917580.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-27T15:08:29Z","receivedAt":"2007-11-27T15:08:29Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:\n> On Tue, 27 Nov 2007, Johannes Schindelin wrote:\n> \n> > Hi,\n> > \n> > On Tue, 27 Nov 2007, しらいしななこ wrote:\n> > \n> > > Was it coded poorly, buggy or were there some other issues?\n> > \n> > It is very well possible that it was coded poorly ;-)\n> > \n> > The main reason, I believe, was that some old-timers who know the \n> > implications said that it would encourage a wrong workflow. One thing \n> > that could go possibly wrong, for example, is to rebase commits that you \n> > already published.\n> \n> Being much more involved in the maintenance of a published Git tree \n> lately, I must disagree with the \"wrong workflow\" statement. Until the \n> stuff I maintain is finally merged upstream, I have to constantly \n> amend/replace/fold/split random commits in my repo to follow the review \n> cycles involved. yet I have to publish the result to let others base \n> their work on top of my latest tree. A fetch+rebase is the only option \n> for those following my tree, and I made it clear that they have to \n> rebase after a fetch because I constantly rebase commits that I have \n> already published myself.\n\nRight. But a rebase \"merge strategy\" doesn't work for those people,\nbecause it's not possible in general for their git to know exactly which\npart is their work (which needs to be rebased) and which is your old\nwork (which should be discarded). Manual inspection is required.\n\n> And in this case, constant rebasing is a perfectly fine work flow to me. \n\nAgain, if you have people basing work on top of yours, I think the best\noption may really be to add a merge commit on top of each new version of\nthe series with first parent the new series and second parent the\nprevious history.\n\nThat way the history does have the information necessary to rebase their\nwork automatically.\n\n--b.\n"},{"id":"61089","messageId":"474C352A.2080708@op5.se","threadId":"11028","inReplyTo":"Pine.LNX.4.64.0711271352050.27959@racer.site","subject":"Re: What's cooking in git.git (topics)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-27T15:18:02Z","receivedAt":"2007-11-27T15:18:02Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 27 Nov 2007, Andreas Ericsson wrote:\n> \n>> Johannes Schindelin wrote:\n>>\n>>> One thing that could go possibly wrong, for example, is to rebase \n>>> commits that you already published.\n>> For the vast majority of git users, that's a non-issue as \"published\" is \n>> usually defined as \"pushed to the publicly advertised watering hole\".\n> \n> No. This is only the \"vast majority of git users told by their peers to \n> use a central repository\".\n> \n\n\nLet me rephrase.\nFor any project large enough to want to attract random hackers, there\nwill always be a single repository considered the public \"master repo\".\nFor such projects code is most likely considered \"published\" when the\ncode hits that repository (or some middle-stage on its way to it).\n\nIt has to do with communication and convenience. When the code reaches\nthat master repo it's no longer easy to communicate the fact that it\nhas been rebased to everyone it's been published to.\n\n\n> Just because you use git like cvs does not mean that you \"use git\".\n> \n\nI suppose Junio and Linus don't \"use git\" either then, as they're both\nin control of at least one such \"master repo\" each. Ah well. At least\nI'm in good company.\n\n\n>> Yes, I'm aware that git is distributed. That doesn't mean that it's not \n>> convenient to have one single place where all code meant to be released \n>> eventually ends up.\n> \n> It may be convenient for you. I do not like it.\n\n\nIt's not only convenient for me. It's convenient for the tens of thousands\nof people working on the Linux kernel to have a single place to go to for\nthat one repository that somehow fathers all the tarballs.\n\nSo long as it's a small group of developers working on something, it's\nobviously not necessary to provide such a place, but when you want to\nattract the huge anonymous coders that you've never spoken to, you need\na single place to post the latest and greatest.\n\n\n> Yes, I even made the \n> mistake with msysGit. In the end, it would have been much more \n> intelligent to set up a repository which others would have had to fork \n> from.\n> \n\nSo? Any new developer wanting to work on it will still try to locate\nthe public copy of the \"master repo\" to start their fork from.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"61090","messageId":"alpine.LFD.0.99999.0711271013310.9605@xanadu.home","threadId":"11028","inReplyTo":"20071127150829.GB3853@fieldses.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-27T15:19:53Z","receivedAt":"2007-11-27T15:19:53Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 27 Nov 2007, J. Bruce Fields wrote:\n\n> On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:\n> > Being much more involved in the maintenance of a published Git tree \n> > lately, I must disagree with the \"wrong workflow\" statement. Until the \n> > stuff I maintain is finally merged upstream, I have to constantly \n> > amend/replace/fold/split random commits in my repo to follow the review \n> > cycles involved. yet I have to publish the result to let others base \n> > their work on top of my latest tree. A fetch+rebase is the only option \n> > for those following my tree, and I made it clear that they have to \n> > rebase after a fetch because I constantly rebase commits that I have \n> > already published myself.\n> \n> Right. But a rebase \"merge strategy\" doesn't work for those people,\n> because it's not possible in general for their git to know exactly which\n> part is their work (which needs to be rebased) and which is your old\n> work (which should be discarded). Manual inspection is required.\n\nI don't follow.\n\nTheir work is always origin/master@{1}..HEAD after origin/master has \nbeen updated through a fetch, and it needs to be rebased on \norigin/master.\n\n> > And in this case, constant rebasing is a perfectly fine work flow to me. \n> \n> Again, if you have people basing work on top of yours, I think the best\n> option may really be to add a merge commit on top of each new version of\n> the series with first parent the new series and second parent the\n> previous history.\n> \n> That way the history does have the information necessary to rebase their\n> work automatically.\n\nAnd my repo will then be full of clutter which no one upstream will ever \naccept to merge. Can't do that.\n\n\nNicolas\n"},{"id":"61093","messageId":"20071127153411.GA11731@fieldses.org","threadId":"11028","inReplyTo":"alpine.LFD.0.99999.0711271013310.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-27T15:34:11Z","receivedAt":"2007-11-27T15:34:11Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Nov 27, 2007 at 10:19:53AM -0500, Nicolas Pitre wrote:\n> On Tue, 27 Nov 2007, J. Bruce Fields wrote:\n> \n> > On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:\n> > > Being much more involved in the maintenance of a published Git tree \n> > > lately, I must disagree with the \"wrong workflow\" statement. Until the \n> > > stuff I maintain is finally merged upstream, I have to constantly \n> > > amend/replace/fold/split random commits in my repo to follow the review \n> > > cycles involved. yet I have to publish the result to let others base \n> > > their work on top of my latest tree. A fetch+rebase is the only option \n> > > for those following my tree, and I made it clear that they have to \n> > > rebase after a fetch because I constantly rebase commits that I have \n> > > already published myself.\n> > \n> > Right. But a rebase \"merge strategy\" doesn't work for those people,\n> > because it's not possible in general for their git to know exactly which\n> > part is their work (which needs to be rebased) and which is your old\n> > work (which should be discarded). Manual inspection is required.\n> \n> I don't follow.\n> \n> Their work is always origin/master@{1}..HEAD after origin/master has \n> been updated through a fetch, and it needs to be rebased on \n> origin/master.\n\nNo, their work isn't always based on origin/master@{1}. Often they've\ngot more than one project going. If they try\n\n\tgit checkout project-1\n\tgit pull -s rebase\n\tgit checkout project-2\n\tgit pull -s rebase\n\nwhat's going to happen? What if project-2 has been on the back burner\nfor a few months and they're just getting around to rebasing it now?\nWhat if their various projects are based on different upstream branches,\nbut the fetch done by git-pull updates them all at once? What if they\ndid a git fetch earlier just to peek at current development and are only\nnow getting around to updating their own branches?\n\nAnd I don't think any of those are crazy corner cases; I know at least\nthat I do all of those things.\n\n> > Again, if you have people basing work on top of yours, I think the best\n> > option may really be to add a merge commit on top of each new version of\n> > the series with first parent the new series and second parent the\n> > previous history.\n> > \n> > That way the history does have the information necessary to rebase their\n> > work automatically.\n> \n> And my repo will then be full of clutter which no one upstream will ever \n> accept to merge. Can't do that.\n\nNo, it's no problem--you just submit branch^. You probably want to give\nit a throw-away name for the purpose of the request-pull message, e.g.:\n\n\tgit branch for-linus HEAD^\n\tgit push my-pub-repo for-linus\n\nthen delete for-linus after you see it merged.\n\nBut use for-linus only for that, and advertise \"branch\" as the base\npeople should be using for ongoing development.\n\nI don't know, maybe it's too complicated. But I think it's the only way\nto get a really robust automated process for the people basing work on\nyour branch.\n\n--b.\n"},{"id":"61096","messageId":"alpine.LFD.0.99999.0711271047590.9605@xanadu.home","threadId":"11028","inReplyTo":"20071127153411.GA11731@fieldses.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-27T16:14:47Z","receivedAt":"2007-11-27T16:14:47Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 27 Nov 2007, J. Bruce Fields wrote:\n\n> On Tue, Nov 27, 2007 at 10:19:53AM -0500, Nicolas Pitre wrote:\n> > On Tue, 27 Nov 2007, J. Bruce Fields wrote:\n> > \n> > > On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:\n> > > > Being much more involved in the maintenance of a published Git tree \n> > > > lately, I must disagree with the \"wrong workflow\" statement. Until the \n> > > > stuff I maintain is finally merged upstream, I have to constantly \n> > > > amend/replace/fold/split random commits in my repo to follow the review \n> > > > cycles involved. yet I have to publish the result to let others base \n> > > > their work on top of my latest tree. A fetch+rebase is the only option \n> > > > for those following my tree, and I made it clear that they have to \n> > > > rebase after a fetch because I constantly rebase commits that I have \n> > > > already published myself.\n> > > \n> > > Right. But a rebase \"merge strategy\" doesn't work for those people,\n> > > because it's not possible in general for their git to know exactly which\n> > > part is their work (which needs to be rebased) and which is your old\n> > > work (which should be discarded). Manual inspection is required.\n> > \n> > I don't follow.\n> > \n> > Their work is always origin/master@{1}..HEAD after origin/master has \n> > been updated through a fetch, and it needs to be rebased on \n> > origin/master.\n> \n> No, their work isn't always based on origin/master@{1}. Often they've\n> got more than one project going. If they try\n> \n> \tgit checkout project-1\n> \tgit pull -s rebase\n> \tgit checkout project-2\n> \tgit pull -s rebase\n> \n> what's going to happen? What if project-2 has been on the back burner\n> for a few months and they're just getting around to rebasing it now?\n\nI don't see the problem. They'll just have a possibly harder rebase due \nto increased chances for conflicts than if they rebased more often, but \nthat's to be expected even with a merge.\n\n> What if their various projects are based on different upstream branches,\n> but the fetch done by git-pull updates them all at once?\n> What if they\n> did a git fetch earlier just to peek at current development and are only\n> now getting around to updating their own branches?\n\nYou are not _forced_ to use origin/master@{1} in that case -- I used \nthat notation only to illustrate the concept in Git terms. What I tell \npeople to do is to tag their new base after the rebase is done, and to \nuse that tag after the next fetch to rebase again.\n\nI honnestly don't use such a tag myself because I think I know what I'm \ndoing when using Git, and therefore I know when origin/master@{1} refers \nto what I really want. But the point is that either that usage of \norigin/master@{1}, or a dedicated tag, or whatever other means to \nretrieve the previous base, could be handled implicitly by the porcelain \nand the user wouldn't have to care as much.\n\nThinking about it, there should be a way to find the proper base even \nwithout explicitly recording it with a tag. If it isn't \norigin/master@{1}, it has to be the first of origin/master@{n} for\nn = [1, ...] reachable from the local work branch before rebasing.\n\n> And I don't think any of those are crazy corner cases; I know at least\n> that I do all of those things.\n\nSure. In which case you certainly fall into the \"know what you're \ndoing\" category too and certainly can find your way towards the proper \nbase ref to use. But again I think that can be automated.\n\n> > > Again, if you have people basing work on top of yours, I think the best\n> > > option may really be to add a merge commit on top of each new version of\n> > > the series with first parent the new series and second parent the\n> > > previous history.\n> > > \n> > > That way the history does have the information necessary to rebase their\n> > > work automatically.\n> > \n> > And my repo will then be full of clutter which no one upstream will ever \n> > accept to merge. Can't do that.\n> \n> No, it's no problem--you just submit branch^. You probably want to give\n> it a throw-away name for the purpose of the request-pull message, e.g.:\n> \n> \tgit branch for-linus HEAD^\n> \tgit push my-pub-repo for-linus\n> \n> then delete for-linus after you see it merged.\n> \n> But use for-linus only for that, and advertise \"branch\" as the base\n> people should be using for ongoing development.\n> \n> I don't know, maybe it's too complicated. But I think it's the only way\n> to get a really robust automated process for the people basing work on\n> your branch.\n\nIt just looks too twisted for my taste when proper automatic rebase \nwithout extra artifacts should be possible.\n\n\nNicolas\n"},{"id":"61101","messageId":"20071127164243.GE11731@fieldses.org","threadId":"11028","inReplyTo":"alpine.LFD.0.99999.0711271047590.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-27T16:42:43Z","receivedAt":"2007-11-27T16:42:43Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Nov 27, 2007 at 11:14:47AM -0500, Nicolas Pitre wrote:\n> On Tue, 27 Nov 2007, J. Bruce Fields wrote:\n> > No, their work isn't always based on origin/master@{1}. Often they've\n> > got more than one project going. If they try\n> > \n> > \tgit checkout project-1\n> > \tgit pull -s rebase\n> > \tgit checkout project-2\n> > \tgit pull -s rebase\n> > \n> > what's going to happen? What if project-2 has been on the back burner\n> > for a few months and they're just getting around to rebasing it now?\n> \n> I don't see the problem. They'll just have a possibly harder rebase due \n> to increased chances for conflicts than if they rebased more often, but \n> that's to be expected even with a merge.\n\nWell, fair enough. It can be much worse than a merge, though--consider\nwhat happens when upstream drops a commit, or replaces a patch by\nanother patch (or patches) that solves the problem in a different way.\n\n> > What if their various projects are based on different upstream branches,\n> > but the fetch done by git-pull updates them all at once?\n> > What if they\n> > did a git fetch earlier just to peek at current development and are only\n> > now getting around to updating their own branches?\n> \n> You are not _forced_ to use origin/master@{1} in that case -- I used \n> that notation only to illustrate the concept in Git terms. What I tell \n> people to do is to tag their new base after the rebase is done, and to \n> use that tag after the next fetch to rebase again.\n\nThat's fine, but it's not an automated process any more.\n\n> I honnestly don't use such a tag myself because I think I know what I'm \n> doing when using Git, and therefore I know when origin/master@{1} refers \n> to what I really want. But the point is that either that usage of \n> origin/master@{1}, or a dedicated tag, or whatever other means to \n> retrieve the previous base, could be handled implicitly by the porcelain \n> and the user wouldn't have to care as much.\n\nOK, so you're imagining a version of \"git pull -s rebase\" that also\nallows specifying the previous base of your series? What would the\nsyntax be? You could do something like stg does and keep extra\ninformation under .git that records the base of each \"patch series\".\nThen you have to figure out how to manage that information and how it\nshould interact with the varoius branch management commands.\n\n> Thinking about it, there should be a way to find the proper base even \n> without explicitly recording it with a tag. If it isn't \n> origin/master@{1}, it has to be the first of origin/master@{n} for\n> n = [1, ...] reachable from the local work branch before rebasing.\n\nThat'll work in some cases. You're almost using the reflog as another\npiece of history to find the \"real\" merge-base.\n\nThat's a little fragile, since reflogs aren't quite \"real\" history. It\ndoesn't work reliably in the \"project that was put on the back burner\"\ncase (because the reflog entries may have expired). It doesn't work if\nwork is done in multiple repositories.\n\n> > And I don't think any of those are crazy corner cases; I know at least\n> > that I do all of those things.\n> \n> Sure. In which case you certainly fall into the \"know what you're \n> doing\" category too and certainly can find your way towards the proper \n> base ref to use.\n\nBeginners are will try those things too, so we'd have to explain the\nlimitations up front.\n\n> But again I think that can be automated.\n\nI'd want to see the algorithm spelled out, and a very convincing\ndescription of exactly which cases it handles.\n\nMy other objection is that \"rebase\" just isn't a merge strategy. I\nthink of a merge strategy takes some HEADs in a produces a single merge\ncommit that connects them.\n\nIf we really want a fetch+rebase script, OK, but call it something other\nthan pull.\n\n--b.\n"},{"id":"61103","messageId":"Pine.LNX.4.64.0711271652070.27959@racer.site","threadId":"11028","inReplyTo":"20071127164243.GE11731@fieldses.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-27T16:54:18Z","receivedAt":"2007-11-27T16:54:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Nov 2007, J. Bruce Fields wrote:\n\n> If we really want a fetch+rebase script, OK, but call it something other \n> than pull.\n\nWhy? pull = fetch + merge only because that was the originally envisioned \nway to pull remote changes into your local working tree. However, I do \nnot see why we should be married to pull being a fetch and a merge for \neternity.\n\nCiao,\nDscho\n"},{"id":"61104","messageId":"20071127170749.GA19136@fieldses.org","threadId":"11028","inReplyTo":"Pine.LNX.4.64.0711271652070.27959@racer.site","subject":"Re: What's cooking in git.git (topics)","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-27T17:07:49Z","receivedAt":"2007-11-27T17:07:49Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Nov 27, 2007 at 04:54:18PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 27 Nov 2007, J. Bruce Fields wrote:\n> \n> > If we really want a fetch+rebase script, OK, but call it something other \n> > than pull.\n> \n> Why? pull = fetch + merge only because that was the originally envisioned \n> way to pull remote changes into your local working tree. However, I do \n> not see why we should be married to pull being a fetch and a merge for \n> eternity.\n\nTwo responses:\n\nFirst, OK, if you want to say \"pull\" means \"fetch something and then\nincorporate it somehow into your current branch\", that doesn't bother me\nquite as much as saying that \"pull\" always means \"fetch + merge\", and\nthat \"rebase\" is really just a special kind of merge. It's clearly not\na merge.\n\nSecond: \"fetch+rebase\" will really have very different properties from\n\"fetch+pull\". It may be possible to make the former behave a little\nlike the latter in some common cases, but it's going to complicated.\nAnd a lot of git-pull documentation is going to end up with clauses like\n\"...except if you're running pull in 'rebase' mode, in which case...\".\nBetter to keep the two cases as separate operations with separate syntax\nand man pages. (But share where it makes sense--e.g. any syntax and\ndocumentation of fetch part should be shared.)\n\n--b.\n"},{"id":"61106","messageId":"7vbq9fd2mp.fsf@gitster.siamese.dyndns.org","threadId":"11028","inReplyTo":"Pine.LNX.4.64.0711271109130.27959@racer.site","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-27T17:22:54Z","receivedAt":"2007-11-27T17:22:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Tue, 27 Nov 2007, しらいしななこ wrote:\n>\n>> Quoting Andreas Ericsson :\n>> \n>> > \"git pull --rebase\" already has an implementation. Dscho cooked one up\n>> > which I've been using since then. It works nicely.\n>> \n>> What is the reason that the option was not added to the official git? \n>> Was it coded poorly, buggy or were there some other issues?\n>\n> It is very well possible that it was coded poorly ;-)\n>\n> The main reason, I believe, was that some old-timers who know the \n> implications said that it would encourage a wrong workflow. One thing \n> that could go possibly wrong, for example, is to rebase commits that you \n> already published.\n>\n> So AFAICT it was deemed not only giving people rope, but making that rope \n> look like a necklace to them.\n\nHmph, that is different from how I remember, and the \"workflow\" argument\nwould not be something I would make if we were having that discussion\ntoday.\n\nI think what happened was that we took a misguided detour to make this\nan option to \"git merge\" (which was _my_ mistake IIRC, sorry), which did\nnot pan out well (because rebase is not \"a different form of merge\").\nAfter that for some reason we failed to follow-up on the topic. We\ncould have gone back to the original \"a pull is integrating following a\nfetch, and the integration does not have to be merge\" approach to see if\nit was workable, but we didn't.\n\nIf people find it useful, I do not think of a huge reason to object to\nthe inclusion. \"Give them rope\" is good ;-)\n"},{"id":"61107","messageId":"alpine.LFD.0.99999.0711271155250.9605@xanadu.home","threadId":"11028","inReplyTo":"20071127164243.GE11731@fieldses.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-27T17:23:29Z","receivedAt":"2007-11-27T17:23:29Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 27 Nov 2007, J. Bruce Fields wrote:\n\n> On Tue, Nov 27, 2007 at 11:14:47AM -0500, Nicolas Pitre wrote:\n> > On Tue, 27 Nov 2007, J. Bruce Fields wrote:\n> > > No, their work isn't always based on origin/master@{1}. Often they've\n> > > got more than one project going. If they try\n> > > \n> > > \tgit checkout project-1\n> > > \tgit pull -s rebase\n> > > \tgit checkout project-2\n> > > \tgit pull -s rebase\n> > > \n> > > what's going to happen? What if project-2 has been on the back burner\n> > > for a few months and they're just getting around to rebasing it now?\n> > \n> > I don't see the problem. They'll just have a possibly harder rebase due \n> > to increased chances for conflicts than if they rebased more often, but \n> > that's to be expected even with a merge.\n> \n> Well, fair enough. It can be much worse than a merge, though--consider\n> what happens when upstream drops a commit, or replaces a patch by\n> another patch (or patches) that solves the problem in a different way.\n\nThat's the whole point for the need to rebase. To others I'm currently \nupstream and I do the above all the time. So I don't see the issue.\n\n> > > What if their various projects are based on different upstream branches,\n> > > but the fetch done by git-pull updates them all at once?\n> > > What if they\n> > > did a git fetch earlier just to peek at current development and are only\n> > > now getting around to updating their own branches?\n> > \n> > You are not _forced_ to use origin/master@{1} in that case -- I used \n> > that notation only to illustrate the concept in Git terms. What I tell \n> > people to do is to tag their new base after the rebase is done, and to \n> > use that tag after the next fetch to rebase again.\n> \n> That's fine, but it's not an automated process any more.\n\nIndeed. I never claimed it was automated, but I'm rather deploring it.\n\n> > I honnestly don't use such a tag myself because I think I know what I'm \n> > doing when using Git, and therefore I know when origin/master@{1} refers \n> > to what I really want. But the point is that either that usage of \n> > origin/master@{1}, or a dedicated tag, or whatever other means to \n> > retrieve the previous base, could be handled implicitly by the porcelain \n> > and the user wouldn't have to care as much.\n> \n> OK, so you're imagining a version of \"git pull -s rebase\" that also\n> allows specifying the previous base of your series? What would the\n> syntax be? You could do something like stg does and keep extra\n> information under .git that records the base of each \"patch series\".\n> Then you have to figure out how to manage that information and how it\n> should interact with the varoius branch management commands.\n\n... which is IMHO the best reason to find a solution that doesn't need \nextra information to be kept.\n\n> > Thinking about it, there should be a way to find the proper base even \n> > without explicitly recording it with a tag. If it isn't \n> > origin/master@{1}, it has to be the first of origin/master@{n} for\n> > n = [1, ...] reachable from the local work branch before rebasing.\n> \n> That'll work in some cases. You're almost using the reflog as another\n> piece of history to find the \"real\" merge-base.\n\nSure. Since it is there, why not use it?\n\n> That's a little fragile, since reflogs aren't quite \"real\" history. It\n> doesn't work reliably in the \"project that was put on the back burner\"\n> case (because the reflog entries may have expired).\n\nTough.\n\nMaybe reflogs should always preserve a minimum of x entries by default \neven if they are older than the expiration threshold.\n\nBut practically speaking, if you've been sitting on your work for so \nlong and you've pruned your reflog then you should always be able to \nlook up your branch history and find the first commit which isn't yours, \nthen use its ID explicitly. And if you forgot enough about that work of \nyours so not to be able to determine that base commit then I probably \ndon't want to trust you anyway. :-)\n\n> It doesn't work if\n> work is done in multiple repositories.\n\nHmmm... would have to think a bit more about that, but it never was a \nreal issue to me so far.\n\n> > > And I don't think any of those are crazy corner cases; I know at least\n> > > that I do all of those things.\n> > \n> > Sure. In which case you certainly fall into the \"know what you're \n> > doing\" category too and certainly can find your way towards the proper \n> > base ref to use.\n> \n> Beginners are will try those things too, so we'd have to explain the\n> limitations up front.\n\nSure. Yet a bunch of Git beginners are doing just well so far with the \nrather terse instructions I provided for manually rebasing their work \nwhen using my repo. So that must not be that bad.\n\n> > But again I think that can be automated.\n> \n> I'd want to see the algorithm spelled out, and a very convincing\n> description of exactly which cases it handles.\n> \n> My other objection is that \"rebase\" just isn't a merge strategy. I\n> think of a merge strategy takes some HEADs in a produces a single merge\n> commit that connects them.\n> \n> If we really want a fetch+rebase script, OK, but call it something other\n> than pull.\n\nI absolutely agree. Anyway, the Git \"pull\" is my own most hated command. \nI always considered it has strange semantics hiding too much of what is \nactually going on, using an artificial concept probably borrowed from BK \nto justify its existence. In all the tutorials for $job I've done so \nfar, I simply never talk about pull nor clone, but rather about init, \n\"git remote\", fetch and merge, with explicit and meaningful branch \nnames. I think that basic commands, even if there is a bit more of \nthem, make Git easier to learn and understand than talking about those \nmagic meta commands hiding the truth away. But hey, this is only my own \nopinion, and after all I'm the one having to deal with those $job people \nin the end.\n\n\nNicolas\n"},{"id":"61108","messageId":"Pine.LNX.4.64.0711271728540.27959@racer.site","threadId":"11028","inReplyTo":"7vbq9fd2mp.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-27T17:29:13Z","receivedAt":"2007-11-27T17:29:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Nov 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Tue, 27 Nov 2007, しらいしななこ wrote:\n> >\n> >> Quoting Andreas Ericsson :\n> >> \n> >> > \"git pull --rebase\" already has an implementation. Dscho cooked one up\n> >> > which I've been using since then. It works nicely.\n> >> \n> >> What is the reason that the option was not added to the official git? \n> >> Was it coded poorly, buggy or were there some other issues?\n> >\n> > It is very well possible that it was coded poorly ;-)\n> >\n> > The main reason, I believe, was that some old-timers who know the \n> > implications said that it would encourage a wrong workflow. One thing \n> > that could go possibly wrong, for example, is to rebase commits that you \n> > already published.\n> >\n> > So AFAICT it was deemed not only giving people rope, but making that rope \n> > look like a necklace to them.\n> \n> Hmph, that is different from how I remember, and the \"workflow\" argument\n> would not be something I would make if we were having that discussion\n> today.\n> \n> I think what happened was that we took a misguided detour to make this\n> an option to \"git merge\" (which was _my_ mistake IIRC, sorry), which did\n> not pan out well (because rebase is not \"a different form of merge\").\n> After that for some reason we failed to follow-up on the topic. We\n> could have gone back to the original \"a pull is integrating following a\n> fetch, and the integration does not have to be merge\" approach to see if\n> it was workable, but we didn't.\n> \n> If people find it useful, I do not think of a huge reason to object to\n> the inclusion. \"Give them rope\" is good ;-)\n\nFWIW the my last reply in that thread was \nhttp://thread.gmane.org/gmane.comp.version-control.git/62382/focus=62405\n\nCiao,\nDscho\n"},{"id":"61187","messageId":"474D22DC.1060408@op5.se","threadId":"11028","inReplyTo":"20071127170749.GA19136@fieldses.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-28T08:12:12Z","receivedAt":"2007-11-28T08:12:12Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"J. Bruce Fields wrote:\n> On Tue, Nov 27, 2007 at 04:54:18PM +0000, Johannes Schindelin wrote:\n>> Hi,\n>>\n>> On Tue, 27 Nov 2007, J. Bruce Fields wrote:\n>>\n>>> If we really want a fetch+rebase script, OK, but call it something other \n>>> than pull.\n>> Why? pull = fetch + merge only because that was the originally envisioned \n>> way to pull remote changes into your local working tree. However, I do \n>> not see why we should be married to pull being a fetch and a merge for \n>> eternity.\n> \n> Two responses:\n> \n> First, OK, if you want to say \"pull\" means \"fetch something and then\n> incorporate it somehow into your current branch\", that doesn't bother me\n> quite as much as saying that \"pull\" always means \"fetch + merge\", and\n> that \"rebase\" is really just a special kind of merge. It's clearly not\n> a merge.\n> \n\nI beg to differ. The end result is identical to a merge (assuming one\nnever does \"git rebase skip\", which otoh could be thought of as one way\nof resolving a merge conflict). It's just history that doesn't turn out\nthe same. git has always been about content, so from that pov, a rebase\nis exactly the same as a merge.\n\n\n> Second: \"fetch+rebase\" will really have very different properties from\n> \"fetch+pull\".\n\n\"fetch+merge\", no?\n\n> It may be possible to make the former behave a little\n> like the latter in some common cases, but it's going to complicated.\n\n\nTrue. I don't think octopus rebase needs to be supported, for example.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"61344","messageId":"7vlk8hzx0g.fsf@gitster.siamese.dyndns.org","threadId":"11028","inReplyTo":"alpine.LFD.0.99999.0711271155250.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-29T01:00:15Z","receivedAt":"2007-11-29T01:00:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> ... In all the tutorials for $job I've done so \n> far, I simply never talk about pull nor clone, but rather about init, \n> \"git remote\", fetch and merge, with explicit and meaningful branch \n> names. I think that basic commands, even if there is a bit more of \n> them, make Git easier to learn and understand than talking about those \n> magic meta commands hiding the truth away.\n\nThat's actually a quite interesting approach for teaching.\n\nThe original \"tutorial\" (now core-tutorial) was similar in spirit; it\nbuilt the user experience by starting at sequence of low level commands,\nand then finally said \"since this is so often used combination, there is\na short-hand for it that does all\". I think the approach would work\nquite well for people who want to use the tool with deep understanding.\n\nHowever, I am not so sure about people who just want canned set of\ninstructions and follow them blindly to get their work done. And I do\nnot think the latter classes of users are necessarily wrong.\n\nSuch a canned set of instructions would (if the project that supplies\nthe cheat-sheet encourages merges instead of rebases) talk about \"clone\nthen commit then push then pull and repeat\", without mentioning what\npull does is fetch+merge nor what fetch means and what merge means, and\nthat would let people get started without deeper understanding.\n\nBut the lack of deeper understanding would hurt them in the longer run\n(e.g. \"my push was rejected with something called non-fast-forward ---\nwhat does that mean and what would I do now?\"). \n"},{"id":"61348","messageId":"20071129010606.GA5856@fieldses.org","threadId":"11028","inReplyTo":"7vlk8hzx0g.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-29T01:06:06Z","receivedAt":"2007-11-29T01:06:06Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Nov 28, 2007 at 05:00:15PM -0800, Junio C Hamano wrote:\n> Nicolas Pitre writes:\n> \n> > ... In all the tutorials for $job I've done so \n> > far, I simply never talk about pull nor clone, but rather about init, \n> > \"git remote\", fetch and merge, with explicit and meaningful branch \n> > names. I think that basic commands, even if there is a bit more of \n> > them, make Git easier to learn and understand than talking about those \n> > magic meta commands hiding the truth away.\n> \n> That's actually a quite interesting approach for teaching.\n> \n> The original \"tutorial\" (now core-tutorial) was similar in spirit; it\n> built the user experience by starting at sequence of low level commands,\n> and then finally said \"since this is so often used combination, there is\n> a short-hand for it that does all\". I think the approach would work\n> quite well for people who want to use the tool with deep understanding.\n\nYeah. I considered doing the above some time ago and ran into some\ndifferences between git-clone and \"git init && git remote add && git\nfetch\"--I think it may have just been that the latter didn't guess the\nHEAD in the same way. That's fixed now, right? Is there any other\ndifference people would run into? If not, I'll work on that. I\nwouldn't want to break things down quite as far as the core-tutorial,\nbut this particular thing is so simple....\n\n--b.\n"},{"id":"61351","messageId":"7vbq9dzvt5.fsf@gitster.siamese.dyndns.org","threadId":"11028","inReplyTo":"20071129010606.GA5856@fieldses.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-29T01:26:14Z","receivedAt":"2007-11-29T01:26:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> Yeah. I considered doing the above some time ago and ran into some\n> differences between git-clone and \"git init && git remote add && git\n> fetch\"--I think it may have just been that the latter didn't guess the\n> HEAD in the same way. That's fixed now, right?\n\n\"git remote add\" by itself does not talk with remote, so unless you let\nit do the initial fetch it is not fixable (and no, \"git remote add -f\"\ncurrently does not do the guesswork either).\n"},{"id":"61379","messageId":"200711290924.12508.johan@herland.net","threadId":"11028","inReplyTo":"7vlk8hzx0g.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-11-29T08:24:12Z","receivedAt":"2007-11-29T08:24:12Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Thursday 29 November 2007, Junio C Hamano wrote:\n> Nicolas Pitre writes:\n> > ... In all the tutorials for $job I've done so \n> > far, I simply never talk about pull nor clone, but rather about init, \n> > \"git remote\", fetch and merge, with explicit and meaningful branch \n> > names. I think that basic commands, even if there is a bit more of \n> > them, make Git easier to learn and understand than talking about those \n> > magic meta commands hiding the truth away.\n> \n> That's actually a quite interesting approach for teaching.\n> \n> The original \"tutorial\" (now core-tutorial) was similar in spirit; it\n> built the user experience by starting at sequence of low level commands,\n> and then finally said \"since this is so often used combination, there is\n> a short-hand for it that does all\". I think the approach would work\n> quite well for people who want to use the tool with deep understanding.\n> \n> However, I am not so sure about people who just want canned set of\n> instructions and follow them blindly to get their work done. And I do\n> not think the latter classes of users are necessarily wrong.\n> \n> Such a canned set of instructions would (if the project that supplies\n> the cheat-sheet encourages merges instead of rebases) talk about \"clone\n> then commit then push then pull and repeat\", without mentioning what\n> pull does is fetch+merge nor what fetch means and what merge means, and\n> that would let people get started without deeper understanding.\n> \n> But the lack of deeper understanding would hurt them in the longer run\n> (e.g. \"my push was rejected with something called non-fast-forward ---\n> what does that mean and what would I do now?\"). \n\nWhat about ending the cheat-sheet with a big fat link to a FAQ? The FAQ \nanswers common questions like the above (resulting from the cheat-sheet \nglossing over the details) with links to appropriate sections in the more \nthorough introduction (core-tutorial), explaining what's _really_ going on.\n\nJust a thought.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"61411","messageId":"alpine.LFD.0.99999.0711291236260.9605@xanadu.home","threadId":"11028","inReplyTo":"7vlk8hzx0g.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-29T17:47:58Z","receivedAt":"2007-11-29T17:47:58Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 28 Nov 2007, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > ... In all the tutorials for $job I've done so \n> > far, I simply never talk about pull nor clone, but rather about init, \n> > \"git remote\", fetch and merge, with explicit and meaningful branch \n> > names. I think that basic commands, even if there is a bit more of \n> > them, make Git easier to learn and understand than talking about those \n> > magic meta commands hiding the truth away.\n> \n> That's actually a quite interesting approach for teaching.\n> \n> The original \"tutorial\" (now core-tutorial) was similar in spirit; it\n> built the user experience by starting at sequence of low level commands,\n> and then finally said \"since this is so often used combination, there is\n> a short-hand for it that does all\". I think the approach would work\n> quite well for people who want to use the tool with deep understanding.\n> \n> However, I am not so sure about people who just want canned set of\n> instructions and follow them blindly to get their work done. And I do\n> not think the latter classes of users are necessarily wrong.\n> \n> Such a canned set of instructions would (if the project that supplies\n> the cheat-sheet encourages merges instead of rebases) talk about \"clone\n> then commit then push then pull and repeat\", without mentioning what\n> pull does is fetch+merge nor what fetch means and what merge means, and\n> that would let people get started without deeper understanding.\n\nSure. However the people for whom I produced the cheat-sheet have to \ndeal with the repo I maintain, which has multiple branches already, and \nusing an explicit \"git remote add\" allows for better names than the \ndefault \"origin\". Right there they become aware of the easy branching \npossibilities of Git.\n\nAnd with a constantly rewritten history in that repo, they have to \nrebase after every fetch and there is no released Git version with a \nshort-hand for fetch+rebase.\n\n\nNicolas\n"}]}