# Re: What's cooking in git.git (topics) 22 messages from 2007-11-27 to 2007-11-29. Participants: しらいしななこ, Johannes Schindelin, Andreas Ericsson, Nicolas Pitre, J. Bruce Fields, Junio C Hamano, Johan Herland. Thread: https://gitlist.dev/t/11028 ## しらいしななこ, 2007-11-27 06:21 Subject: Re: What's cooking in git.git (topics) Message-ID: <200711270622.lAR6MFXQ010010@mi0.bluebottle.com> URL: https://gitlist.dev/e/200711270622.lAR6MFXQ010010%40mi0.bluebottle.com ``` Quoting Andreas Ericsson : > "git pull --rebase" already has an implementation. Dscho cooked one up > which I've been using since then. It works nicely. What is the reason that the option was not added to the official git? Was it coded poorly, buggy or were there some other issues? -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ ---------------------------------------------------------------------- Find out how you can get spam free email. http://www.bluebottle.com/tag/3 ``` ## Johannes Schindelin, 2007-11-27 11:12 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0711271109130.27959%40racer.site In-Reply-To: <200711270622.lAR6MFXQ010010@mi0.bluebottle.com> ``` Hi, On Tue, 27 Nov 2007, しらいしななこ wrote: > Quoting Andreas Ericsson : > > > "git pull --rebase" already has an implementation. Dscho cooked one up > > which I've been using since then. It works nicely. > > What is the reason that the option was not added to the official git? > Was it coded poorly, buggy or were there some other issues? It is very well possible that it was coded poorly ;-) The main reason, I believe, was that some old-timers who know the implications said that it would encourage a wrong workflow. One thing that could go possibly wrong, for example, is to rebase commits that you already published. So AFAICT it was deemed not only giving people rope, but making that rope look like a necklace to them. Ciao, Dscho ``` ## Andreas Ericsson, 2007-11-27 13:45 Subject: Re: What's cooking in git.git (topics) Message-ID: <474C1F80.5060404@op5.se> URL: https://gitlist.dev/e/474C1F80.5060404%40op5.se In-Reply-To: ``` Johannes Schindelin wrote: > Hi, > > On Tue, 27 Nov 2007, しらいしななこ wrote: > >> Quoting Andreas Ericsson : >> >>> "git pull --rebase" already has an implementation. Dscho cooked one up >>> which I've been using since then. It works nicely. >> What is the reason that the option was not added to the official git? >> Was it coded poorly, buggy or were there some other issues? > > It is very well possible that it was coded poorly ;-) > > The main reason, I believe, was that some old-timers who know the > implications said that it would encourage a wrong workflow. If by "wrong", those old-timers meant "a workflow not commonly used in a published one-pushes-many-pulls repository", I certainly agree. > One thing > that could go possibly wrong, for example, is to rebase commits that you > already published. > For the vast majority of git users, that's a non-issue as "published" is usually defined as "pushed to the publicly advertised watering hole". Yes, I'm aware that git is distributed. That doesn't mean that it's not convenient to have one single place where all code meant to be released eventually ends up. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ``` ## Johannes Schindelin, 2007-11-27 13:54 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0711271352050.27959%40racer.site In-Reply-To: <474C1F80.5060404@op5.se> ``` Hi, On Tue, 27 Nov 2007, Andreas Ericsson wrote: > Johannes Schindelin wrote: > > > One thing that could go possibly wrong, for example, is to rebase > > commits that you already published. > > For the vast majority of git users, that's a non-issue as "published" is > usually defined as "pushed to the publicly advertised watering hole". No. This is only the "vast majority of git users told by their peers to use a central repository". Just because you use git like cvs does not mean that you "use git". > Yes, I'm aware that git is distributed. That doesn't mean that it's not > convenient to have one single place where all code meant to be released > eventually ends up. It may be convenient for you. I do not like it. Yes, I even made the mistake with msysGit. In the end, it would have been much more intelligent to set up a repository which others would have had to fork from. Ciao, Dscho ``` ## Nicolas Pitre, 2007-11-27 14:29 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.99999.0711270917580.9605%40xanadu.home In-Reply-To: ``` On Tue, 27 Nov 2007, Johannes Schindelin wrote: > Hi, > > On Tue, 27 Nov 2007, しらいしななこ wrote: > > > Was it coded poorly, buggy or were there some other issues? > > It is very well possible that it was coded poorly ;-) > > The main reason, I believe, was that some old-timers who know the > implications said that it would encourage a wrong workflow. One thing > that could go possibly wrong, for example, is to rebase commits that you > already published. Being much more involved in the maintenance of a published Git tree lately, I must disagree with the "wrong workflow" statement. Until the stuff I maintain is finally merged upstream, I have to constantly amend/replace/fold/split random commits in my repo to follow the review cycles involved. yet I have to publish the result to let others base their work on top of my latest tree. A fetch+rebase is the only option for those following my tree, and I made it clear that they have to rebase after a fetch because I constantly rebase commits that I have already published myself. And in this case, constant rebasing is a perfectly fine work flow to me. Otherwise I might just use Git as a glorified tarball downloader and use quilt on top, but this is somehow not as appealing. Nicolas ``` ## J. Bruce Fields, 2007-11-27 15:08 Subject: Re: What's cooking in git.git (topics) Message-ID: <20071127150829.GB3853@fieldses.org> URL: https://gitlist.dev/e/20071127150829.GB3853%40fieldses.org In-Reply-To: ``` On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote: > On Tue, 27 Nov 2007, Johannes Schindelin wrote: > > > Hi, > > > > On Tue, 27 Nov 2007, しらいしななこ wrote: > > > > > Was it coded poorly, buggy or were there some other issues? > > > > It is very well possible that it was coded poorly ;-) > > > > The main reason, I believe, was that some old-timers who know the > > implications said that it would encourage a wrong workflow. One thing > > that could go possibly wrong, for example, is to rebase commits that you > > already published. > > Being much more involved in the maintenance of a published Git tree > lately, I must disagree with the "wrong workflow" statement. Until the > stuff I maintain is finally merged upstream, I have to constantly > amend/replace/fold/split random commits in my repo to follow the review > cycles involved. yet I have to publish the result to let others base > their work on top of my latest tree. A fetch+rebase is the only option > for those following my tree, and I made it clear that they have to > rebase after a fetch because I constantly rebase commits that I have > already published myself. Right. But a rebase "merge strategy" doesn't work for those people, because it's not possible in general for their git to know exactly which part is their work (which needs to be rebased) and which is your old work (which should be discarded). Manual inspection is required. > And in this case, constant rebasing is a perfectly fine work flow to me. Again, if you have people basing work on top of yours, I think the best option may really be to add a merge commit on top of each new version of the series with first parent the new series and second parent the previous history. That way the history does have the information necessary to rebase their work automatically. --b. ``` ## Andreas Ericsson, 2007-11-27 15:18 Subject: Re: What's cooking in git.git (topics) Message-ID: <474C352A.2080708@op5.se> URL: https://gitlist.dev/e/474C352A.2080708%40op5.se In-Reply-To: ``` Johannes Schindelin wrote: > Hi, > > On Tue, 27 Nov 2007, Andreas Ericsson wrote: > >> Johannes Schindelin wrote: >> >>> One thing that could go possibly wrong, for example, is to rebase >>> commits that you already published. >> For the vast majority of git users, that's a non-issue as "published" is >> usually defined as "pushed to the publicly advertised watering hole". > > No. This is only the "vast majority of git users told by their peers to > use a central repository". > Let me rephrase. For any project large enough to want to attract random hackers, there will always be a single repository considered the public "master repo". For such projects code is most likely considered "published" when the code hits that repository (or some middle-stage on its way to it). It has to do with communication and convenience. When the code reaches that master repo it's no longer easy to communicate the fact that it has been rebased to everyone it's been published to. > Just because you use git like cvs does not mean that you "use git". > I suppose Junio and Linus don't "use git" either then, as they're both in control of at least one such "master repo" each. Ah well. At least I'm in good company. >> Yes, I'm aware that git is distributed. That doesn't mean that it's not >> convenient to have one single place where all code meant to be released >> eventually ends up. > > It may be convenient for you. I do not like it. It's not only convenient for me. It's convenient for the tens of thousands of people working on the Linux kernel to have a single place to go to for that one repository that somehow fathers all the tarballs. So long as it's a small group of developers working on something, it's obviously not necessary to provide such a place, but when you want to attract the huge anonymous coders that you've never spoken to, you need a single place to post the latest and greatest. > Yes, I even made the > mistake with msysGit. In the end, it would have been much more > intelligent to set up a repository which others would have had to fork > from. > So? Any new developer wanting to work on it will still try to locate the public copy of the "master repo" to start their fork from. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ``` ## Nicolas Pitre, 2007-11-27 15:19 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.99999.0711271013310.9605%40xanadu.home In-Reply-To: <20071127150829.GB3853@fieldses.org> ``` On Tue, 27 Nov 2007, J. Bruce Fields wrote: > On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote: > > Being much more involved in the maintenance of a published Git tree > > lately, I must disagree with the "wrong workflow" statement. Until the > > stuff I maintain is finally merged upstream, I have to constantly > > amend/replace/fold/split random commits in my repo to follow the review > > cycles involved. yet I have to publish the result to let others base > > their work on top of my latest tree. A fetch+rebase is the only option > > for those following my tree, and I made it clear that they have to > > rebase after a fetch because I constantly rebase commits that I have > > already published myself. > > Right. But a rebase "merge strategy" doesn't work for those people, > because it's not possible in general for their git to know exactly which > part is their work (which needs to be rebased) and which is your old > work (which should be discarded). Manual inspection is required. I don't follow. Their work is always origin/master@{1}..HEAD after origin/master has been updated through a fetch, and it needs to be rebased on origin/master. > > And in this case, constant rebasing is a perfectly fine work flow to me. > > Again, if you have people basing work on top of yours, I think the best > option may really be to add a merge commit on top of each new version of > the series with first parent the new series and second parent the > previous history. > > That way the history does have the information necessary to rebase their > work automatically. And my repo will then be full of clutter which no one upstream will ever accept to merge. Can't do that. Nicolas ``` ## J. Bruce Fields, 2007-11-27 15:34 Subject: Re: What's cooking in git.git (topics) Message-ID: <20071127153411.GA11731@fieldses.org> URL: https://gitlist.dev/e/20071127153411.GA11731%40fieldses.org In-Reply-To: ``` On Tue, Nov 27, 2007 at 10:19:53AM -0500, Nicolas Pitre wrote: > On Tue, 27 Nov 2007, J. Bruce Fields wrote: > > > On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote: > > > Being much more involved in the maintenance of a published Git tree > > > lately, I must disagree with the "wrong workflow" statement. Until the > > > stuff I maintain is finally merged upstream, I have to constantly > > > amend/replace/fold/split random commits in my repo to follow the review > > > cycles involved. yet I have to publish the result to let others base > > > their work on top of my latest tree. A fetch+rebase is the only option > > > for those following my tree, and I made it clear that they have to > > > rebase after a fetch because I constantly rebase commits that I have > > > already published myself. > > > > Right. But a rebase "merge strategy" doesn't work for those people, > > because it's not possible in general for their git to know exactly which > > part is their work (which needs to be rebased) and which is your old > > work (which should be discarded). Manual inspection is required. > > I don't follow. > > Their work is always origin/master@{1}..HEAD after origin/master has > been updated through a fetch, and it needs to be rebased on > origin/master. No, their work isn't always based on origin/master@{1}. Often they've got more than one project going. If they try git checkout project-1 git pull -s rebase git checkout project-2 git pull -s rebase what's going to happen? What if project-2 has been on the back burner for a few months and they're just getting around to rebasing it now? What if their various projects are based on different upstream branches, but the fetch done by git-pull updates them all at once? What if they did a git fetch earlier just to peek at current development and are only now getting around to updating their own branches? And I don't think any of those are crazy corner cases; I know at least that I do all of those things. > > Again, if you have people basing work on top of yours, I think the best > > option may really be to add a merge commit on top of each new version of > > the series with first parent the new series and second parent the > > previous history. > > > > That way the history does have the information necessary to rebase their > > work automatically. > > And my repo will then be full of clutter which no one upstream will ever > accept to merge. Can't do that. No, it's no problem--you just submit branch^. You probably want to give it a throw-away name for the purpose of the request-pull message, e.g.: git branch for-linus HEAD^ git push my-pub-repo for-linus then delete for-linus after you see it merged. But use for-linus only for that, and advertise "branch" as the base people should be using for ongoing development. I don't know, maybe it's too complicated. But I think it's the only way to get a really robust automated process for the people basing work on your branch. --b. ``` ## Nicolas Pitre, 2007-11-27 16:14 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.99999.0711271047590.9605%40xanadu.home In-Reply-To: <20071127153411.GA11731@fieldses.org> ``` On Tue, 27 Nov 2007, J. Bruce Fields wrote: > On Tue, Nov 27, 2007 at 10:19:53AM -0500, Nicolas Pitre wrote: > > On Tue, 27 Nov 2007, J. Bruce Fields wrote: > > > > > On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote: > > > > Being much more involved in the maintenance of a published Git tree > > > > lately, I must disagree with the "wrong workflow" statement. Until the > > > > stuff I maintain is finally merged upstream, I have to constantly > > > > amend/replace/fold/split random commits in my repo to follow the review > > > > cycles involved. yet I have to publish the result to let others base > > > > their work on top of my latest tree. A fetch+rebase is the only option > > > > for those following my tree, and I made it clear that they have to > > > > rebase after a fetch because I constantly rebase commits that I have > > > > already published myself. > > > > > > Right. But a rebase "merge strategy" doesn't work for those people, > > > because it's not possible in general for their git to know exactly which > > > part is their work (which needs to be rebased) and which is your old > > > work (which should be discarded). Manual inspection is required. > > > > I don't follow. > > > > Their work is always origin/master@{1}..HEAD after origin/master has > > been updated through a fetch, and it needs to be rebased on > > origin/master. > > No, their work isn't always based on origin/master@{1}. Often they've > got more than one project going. If they try > > git checkout project-1 > git pull -s rebase > git checkout project-2 > git pull -s rebase > > what's going to happen? What if project-2 has been on the back burner > for a few months and they're just getting around to rebasing it now? I don't see the problem. They'll just have a possibly harder rebase due to increased chances for conflicts than if they rebased more often, but that's to be expected even with a merge. > What if their various projects are based on different upstream branches, > but the fetch done by git-pull updates them all at once? > What if they > did a git fetch earlier just to peek at current development and are only > now getting around to updating their own branches? You are not _forced_ to use origin/master@{1} in that case -- I used that notation only to illustrate the concept in Git terms. What I tell people to do is to tag their new base after the rebase is done, and to use that tag after the next fetch to rebase again. I honnestly don't use such a tag myself because I think I know what I'm doing when using Git, and therefore I know when origin/master@{1} refers to what I really want. But the point is that either that usage of origin/master@{1}, or a dedicated tag, or whatever other means to retrieve the previous base, could be handled implicitly by the porcelain and the user wouldn't have to care as much. Thinking about it, there should be a way to find the proper base even without explicitly recording it with a tag. If it isn't origin/master@{1}, it has to be the first of origin/master@{n} for n = [1, ...] reachable from the local work branch before rebasing. > And I don't think any of those are crazy corner cases; I know at least > that I do all of those things. Sure. In which case you certainly fall into the "know what you're doing" category too and certainly can find your way towards the proper base ref to use. But again I think that can be automated. > > > Again, if you have people basing work on top of yours, I think the best > > > option may really be to add a merge commit on top of each new version of > > > the series with first parent the new series and second parent the > > > previous history. > > > > > > That way the history does have the information necessary to rebase their > > > work automatically. > > > > And my repo will then be full of clutter which no one upstream will ever > > accept to merge. Can't do that. > > No, it's no problem--you just submit branch^. You probably want to give > it a throw-away name for the purpose of the request-pull message, e.g.: > > git branch for-linus HEAD^ > git push my-pub-repo for-linus > > then delete for-linus after you see it merged. > > But use for-linus only for that, and advertise "branch" as the base > people should be using for ongoing development. > > I don't know, maybe it's too complicated. But I think it's the only way > to get a really robust automated process for the people basing work on > your branch. It just looks too twisted for my taste when proper automatic rebase without extra artifacts should be possible. Nicolas ``` ## J. Bruce Fields, 2007-11-27 16:42 Subject: Re: What's cooking in git.git (topics) Message-ID: <20071127164243.GE11731@fieldses.org> URL: https://gitlist.dev/e/20071127164243.GE11731%40fieldses.org In-Reply-To: ``` On Tue, Nov 27, 2007 at 11:14:47AM -0500, Nicolas Pitre wrote: > On Tue, 27 Nov 2007, J. Bruce Fields wrote: > > No, their work isn't always based on origin/master@{1}. Often they've > > got more than one project going. If they try > > > > git checkout project-1 > > git pull -s rebase > > git checkout project-2 > > git pull -s rebase > > > > what's going to happen? What if project-2 has been on the back burner > > for a few months and they're just getting around to rebasing it now? > > I don't see the problem. They'll just have a possibly harder rebase due > to increased chances for conflicts than if they rebased more often, but > that's to be expected even with a merge. Well, fair enough. It can be much worse than a merge, though--consider what happens when upstream drops a commit, or replaces a patch by another patch (or patches) that solves the problem in a different way. > > What if their various projects are based on different upstream branches, > > but the fetch done by git-pull updates them all at once? > > What if they > > did a git fetch earlier just to peek at current development and are only > > now getting around to updating their own branches? > > You are not _forced_ to use origin/master@{1} in that case -- I used > that notation only to illustrate the concept in Git terms. What I tell > people to do is to tag their new base after the rebase is done, and to > use that tag after the next fetch to rebase again. That's fine, but it's not an automated process any more. > I honnestly don't use such a tag myself because I think I know what I'm > doing when using Git, and therefore I know when origin/master@{1} refers > to what I really want. But the point is that either that usage of > origin/master@{1}, or a dedicated tag, or whatever other means to > retrieve the previous base, could be handled implicitly by the porcelain > and the user wouldn't have to care as much. OK, so you're imagining a version of "git pull -s rebase" that also allows specifying the previous base of your series? What would the syntax be? You could do something like stg does and keep extra information under .git that records the base of each "patch series". Then you have to figure out how to manage that information and how it should interact with the varoius branch management commands. > Thinking about it, there should be a way to find the proper base even > without explicitly recording it with a tag. If it isn't > origin/master@{1}, it has to be the first of origin/master@{n} for > n = [1, ...] reachable from the local work branch before rebasing. That'll work in some cases. You're almost using the reflog as another piece of history to find the "real" merge-base. That's a little fragile, since reflogs aren't quite "real" history. It doesn't work reliably in the "project that was put on the back burner" case (because the reflog entries may have expired). It doesn't work if work is done in multiple repositories. > > And I don't think any of those are crazy corner cases; I know at least > > that I do all of those things. > > Sure. In which case you certainly fall into the "know what you're > doing" category too and certainly can find your way towards the proper > base ref to use. Beginners are will try those things too, so we'd have to explain the limitations up front. > But again I think that can be automated. I'd want to see the algorithm spelled out, and a very convincing description of exactly which cases it handles. My other objection is that "rebase" just isn't a merge strategy. I think of a merge strategy takes some HEADs in a produces a single merge commit that connects them. If we really want a fetch+rebase script, OK, but call it something other than pull. --b. ``` ## Johannes Schindelin, 2007-11-27 16:54 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0711271652070.27959%40racer.site In-Reply-To: <20071127164243.GE11731@fieldses.org> ``` Hi, On Tue, 27 Nov 2007, J. Bruce Fields wrote: > If we really want a fetch+rebase script, OK, but call it something other > than pull. Why? pull = fetch + merge only because that was the originally envisioned way to pull remote changes into your local working tree. However, I do not see why we should be married to pull being a fetch and a merge for eternity. Ciao, Dscho ``` ## J. Bruce Fields, 2007-11-27 17:07 Subject: Re: What's cooking in git.git (topics) Message-ID: <20071127170749.GA19136@fieldses.org> URL: https://gitlist.dev/e/20071127170749.GA19136%40fieldses.org In-Reply-To: ``` On Tue, Nov 27, 2007 at 04:54:18PM +0000, Johannes Schindelin wrote: > Hi, > > On Tue, 27 Nov 2007, J. Bruce Fields wrote: > > > If we really want a fetch+rebase script, OK, but call it something other > > than pull. > > Why? pull = fetch + merge only because that was the originally envisioned > way to pull remote changes into your local working tree. However, I do > not see why we should be married to pull being a fetch and a merge for > eternity. Two responses: First, OK, if you want to say "pull" means "fetch something and then incorporate it somehow into your current branch", that doesn't bother me quite as much as saying that "pull" always means "fetch + merge", and that "rebase" is really just a special kind of merge. It's clearly not a merge. Second: "fetch+rebase" will really have very different properties from "fetch+pull". It may be possible to make the former behave a little like the latter in some common cases, but it's going to complicated. And a lot of git-pull documentation is going to end up with clauses like "...except if you're running pull in 'rebase' mode, in which case...". Better to keep the two cases as separate operations with separate syntax and man pages. (But share where it makes sense--e.g. any syntax and documentation of fetch part should be shared.) --b. ``` ## Junio C Hamano, 2007-11-27 17:22 Subject: Re: What's cooking in git.git (topics) Message-ID: <7vbq9fd2mp.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vbq9fd2mp.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Johannes Schindelin writes: > On Tue, 27 Nov 2007, しらいしななこ wrote: > >> Quoting Andreas Ericsson : >> >> > "git pull --rebase" already has an implementation. Dscho cooked one up >> > which I've been using since then. It works nicely. >> >> What is the reason that the option was not added to the official git? >> Was it coded poorly, buggy or were there some other issues? > > It is very well possible that it was coded poorly ;-) > > The main reason, I believe, was that some old-timers who know the > implications said that it would encourage a wrong workflow. One thing > that could go possibly wrong, for example, is to rebase commits that you > already published. > > So AFAICT it was deemed not only giving people rope, but making that rope > look like a necklace to them. Hmph, that is different from how I remember, and the "workflow" argument would not be something I would make if we were having that discussion today. I think what happened was that we took a misguided detour to make this an option to "git merge" (which was _my_ mistake IIRC, sorry), which did not pan out well (because rebase is not "a different form of merge"). After that for some reason we failed to follow-up on the topic. We could have gone back to the original "a pull is integrating following a fetch, and the integration does not have to be merge" approach to see if it was workable, but we didn't. If people find it useful, I do not think of a huge reason to object to the inclusion. "Give them rope" is good ;-) ``` ## Nicolas Pitre, 2007-11-27 17:23 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.99999.0711271155250.9605%40xanadu.home In-Reply-To: <20071127164243.GE11731@fieldses.org> ``` On Tue, 27 Nov 2007, J. Bruce Fields wrote: > On Tue, Nov 27, 2007 at 11:14:47AM -0500, Nicolas Pitre wrote: > > On Tue, 27 Nov 2007, J. Bruce Fields wrote: > > > No, their work isn't always based on origin/master@{1}. Often they've > > > got more than one project going. If they try > > > > > > git checkout project-1 > > > git pull -s rebase > > > git checkout project-2 > > > git pull -s rebase > > > > > > what's going to happen? What if project-2 has been on the back burner > > > for a few months and they're just getting around to rebasing it now? > > > > I don't see the problem. They'll just have a possibly harder rebase due > > to increased chances for conflicts than if they rebased more often, but > > that's to be expected even with a merge. > > Well, fair enough. It can be much worse than a merge, though--consider > what happens when upstream drops a commit, or replaces a patch by > another patch (or patches) that solves the problem in a different way. That's the whole point for the need to rebase. To others I'm currently upstream and I do the above all the time. So I don't see the issue. > > > What if their various projects are based on different upstream branches, > > > but the fetch done by git-pull updates them all at once? > > > What if they > > > did a git fetch earlier just to peek at current development and are only > > > now getting around to updating their own branches? > > > > You are not _forced_ to use origin/master@{1} in that case -- I used > > that notation only to illustrate the concept in Git terms. What I tell > > people to do is to tag their new base after the rebase is done, and to > > use that tag after the next fetch to rebase again. > > That's fine, but it's not an automated process any more. Indeed. I never claimed it was automated, but I'm rather deploring it. > > I honnestly don't use such a tag myself because I think I know what I'm > > doing when using Git, and therefore I know when origin/master@{1} refers > > to what I really want. But the point is that either that usage of > > origin/master@{1}, or a dedicated tag, or whatever other means to > > retrieve the previous base, could be handled implicitly by the porcelain > > and the user wouldn't have to care as much. > > OK, so you're imagining a version of "git pull -s rebase" that also > allows specifying the previous base of your series? What would the > syntax be? You could do something like stg does and keep extra > information under .git that records the base of each "patch series". > Then you have to figure out how to manage that information and how it > should interact with the varoius branch management commands. ... which is IMHO the best reason to find a solution that doesn't need extra information to be kept. > > Thinking about it, there should be a way to find the proper base even > > without explicitly recording it with a tag. If it isn't > > origin/master@{1}, it has to be the first of origin/master@{n} for > > n = [1, ...] reachable from the local work branch before rebasing. > > That'll work in some cases. You're almost using the reflog as another > piece of history to find the "real" merge-base. Sure. Since it is there, why not use it? > That's a little fragile, since reflogs aren't quite "real" history. It > doesn't work reliably in the "project that was put on the back burner" > case (because the reflog entries may have expired). Tough. Maybe reflogs should always preserve a minimum of x entries by default even if they are older than the expiration threshold. But practically speaking, if you've been sitting on your work for so long and you've pruned your reflog then you should always be able to look up your branch history and find the first commit which isn't yours, then use its ID explicitly. And if you forgot enough about that work of yours so not to be able to determine that base commit then I probably don't want to trust you anyway. :-) > It doesn't work if > work is done in multiple repositories. Hmmm... would have to think a bit more about that, but it never was a real issue to me so far. > > > And I don't think any of those are crazy corner cases; I know at least > > > that I do all of those things. > > > > Sure. In which case you certainly fall into the "know what you're > > doing" category too and certainly can find your way towards the proper > > base ref to use. > > Beginners are will try those things too, so we'd have to explain the > limitations up front. Sure. Yet a bunch of Git beginners are doing just well so far with the rather terse instructions I provided for manually rebasing their work when using my repo. So that must not be that bad. > > But again I think that can be automated. > > I'd want to see the algorithm spelled out, and a very convincing > description of exactly which cases it handles. > > My other objection is that "rebase" just isn't a merge strategy. I > think of a merge strategy takes some HEADs in a produces a single merge > commit that connects them. > > If we really want a fetch+rebase script, OK, but call it something other > than pull. I absolutely agree. Anyway, the Git "pull" is my own most hated command. I always considered it has strange semantics hiding too much of what is actually going on, using an artificial concept probably borrowed from BK to justify its existence. In all the tutorials for $job I've done so far, I simply never talk about pull nor clone, but rather about init, "git remote", fetch and merge, with explicit and meaningful branch names. I think that basic commands, even if there is a bit more of them, make Git easier to learn and understand than talking about those magic meta commands hiding the truth away. But hey, this is only my own opinion, and after all I'm the one having to deal with those $job people in the end. Nicolas ``` ## Johannes Schindelin, 2007-11-27 17:29 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0711271728540.27959%40racer.site In-Reply-To: <7vbq9fd2mp.fsf@gitster.siamese.dyndns.org> ``` Hi, On Tue, 27 Nov 2007, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Tue, 27 Nov 2007, しらいしななこ wrote: > > > >> Quoting Andreas Ericsson : > >> > >> > "git pull --rebase" already has an implementation. Dscho cooked one up > >> > which I've been using since then. It works nicely. > >> > >> What is the reason that the option was not added to the official git? > >> Was it coded poorly, buggy or were there some other issues? > > > > It is very well possible that it was coded poorly ;-) > > > > The main reason, I believe, was that some old-timers who know the > > implications said that it would encourage a wrong workflow. One thing > > that could go possibly wrong, for example, is to rebase commits that you > > already published. > > > > So AFAICT it was deemed not only giving people rope, but making that rope > > look like a necklace to them. > > Hmph, that is different from how I remember, and the "workflow" argument > would not be something I would make if we were having that discussion > today. > > I think what happened was that we took a misguided detour to make this > an option to "git merge" (which was _my_ mistake IIRC, sorry), which did > not pan out well (because rebase is not "a different form of merge"). > After that for some reason we failed to follow-up on the topic. We > could have gone back to the original "a pull is integrating following a > fetch, and the integration does not have to be merge" approach to see if > it was workable, but we didn't. > > If people find it useful, I do not think of a huge reason to object to > the inclusion. "Give them rope" is good ;-) FWIW the my last reply in that thread was http://thread.gmane.org/gmane.comp.version-control.git/62382/focus=62405 Ciao, Dscho ``` ## Andreas Ericsson, 2007-11-28 08:12 Subject: Re: What's cooking in git.git (topics) Message-ID: <474D22DC.1060408@op5.se> URL: https://gitlist.dev/e/474D22DC.1060408%40op5.se In-Reply-To: <20071127170749.GA19136@fieldses.org> ``` J. Bruce Fields wrote: > On Tue, Nov 27, 2007 at 04:54:18PM +0000, Johannes Schindelin wrote: >> Hi, >> >> On Tue, 27 Nov 2007, J. Bruce Fields wrote: >> >>> If we really want a fetch+rebase script, OK, but call it something other >>> than pull. >> Why? pull = fetch + merge only because that was the originally envisioned >> way to pull remote changes into your local working tree. However, I do >> not see why we should be married to pull being a fetch and a merge for >> eternity. > > Two responses: > > First, OK, if you want to say "pull" means "fetch something and then > incorporate it somehow into your current branch", that doesn't bother me > quite as much as saying that "pull" always means "fetch + merge", and > that "rebase" is really just a special kind of merge. It's clearly not > a merge. > I beg to differ. The end result is identical to a merge (assuming one never does "git rebase skip", which otoh could be thought of as one way of resolving a merge conflict). It's just history that doesn't turn out the same. git has always been about content, so from that pov, a rebase is exactly the same as a merge. > Second: "fetch+rebase" will really have very different properties from > "fetch+pull". "fetch+merge", no? > It may be possible to make the former behave a little > like the latter in some common cases, but it's going to complicated. True. I don't think octopus rebase needs to be supported, for example. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ``` ## Junio C Hamano, 2007-11-29 01:00 Subject: Re: What's cooking in git.git (topics) Message-ID: <7vlk8hzx0g.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vlk8hzx0g.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Nicolas Pitre writes: > ... In all the tutorials for $job I've done so > far, I simply never talk about pull nor clone, but rather about init, > "git remote", fetch and merge, with explicit and meaningful branch > names. I think that basic commands, even if there is a bit more of > them, make Git easier to learn and understand than talking about those > magic meta commands hiding the truth away. That's actually a quite interesting approach for teaching. The original "tutorial" (now core-tutorial) was similar in spirit; it built the user experience by starting at sequence of low level commands, and then finally said "since this is so often used combination, there is a short-hand for it that does all". I think the approach would work quite well for people who want to use the tool with deep understanding. However, I am not so sure about people who just want canned set of instructions and follow them blindly to get their work done. And I do not think the latter classes of users are necessarily wrong. Such a canned set of instructions would (if the project that supplies the cheat-sheet encourages merges instead of rebases) talk about "clone then commit then push then pull and repeat", without mentioning what pull does is fetch+merge nor what fetch means and what merge means, and that would let people get started without deeper understanding. But the lack of deeper understanding would hurt them in the longer run (e.g. "my push was rejected with something called non-fast-forward --- what does that mean and what would I do now?"). ``` ## J. Bruce Fields, 2007-11-29 01:06 Subject: Re: What's cooking in git.git (topics) Message-ID: <20071129010606.GA5856@fieldses.org> URL: https://gitlist.dev/e/20071129010606.GA5856%40fieldses.org In-Reply-To: <7vlk8hzx0g.fsf@gitster.siamese.dyndns.org> ``` On Wed, Nov 28, 2007 at 05:00:15PM -0800, Junio C Hamano wrote: > Nicolas Pitre writes: > > > ... In all the tutorials for $job I've done so > > far, I simply never talk about pull nor clone, but rather about init, > > "git remote", fetch and merge, with explicit and meaningful branch > > names. I think that basic commands, even if there is a bit more of > > them, make Git easier to learn and understand than talking about those > > magic meta commands hiding the truth away. > > That's actually a quite interesting approach for teaching. > > The original "tutorial" (now core-tutorial) was similar in spirit; it > built the user experience by starting at sequence of low level commands, > and then finally said "since this is so often used combination, there is > a short-hand for it that does all". I think the approach would work > quite well for people who want to use the tool with deep understanding. Yeah. I considered doing the above some time ago and ran into some differences between git-clone and "git init && git remote add && git fetch"--I think it may have just been that the latter didn't guess the HEAD in the same way. That's fixed now, right? Is there any other difference people would run into? If not, I'll work on that. I wouldn't want to break things down quite as far as the core-tutorial, but this particular thing is so simple.... --b. ``` ## Junio C Hamano, 2007-11-29 01:26 Subject: Re: What's cooking in git.git (topics) Message-ID: <7vbq9dzvt5.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vbq9dzvt5.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20071129010606.GA5856@fieldses.org> ``` "J. Bruce Fields" writes: > Yeah. I considered doing the above some time ago and ran into some > differences between git-clone and "git init && git remote add && git > fetch"--I think it may have just been that the latter didn't guess the > HEAD in the same way. That's fixed now, right? "git remote add" by itself does not talk with remote, so unless you let it do the initial fetch it is not fixable (and no, "git remote add -f" currently does not do the guesswork either). ``` ## Johan Herland, 2007-11-29 08:24 Subject: Re: What's cooking in git.git (topics) Message-ID: <200711290924.12508.johan@herland.net> URL: https://gitlist.dev/e/200711290924.12508.johan%40herland.net In-Reply-To: <7vlk8hzx0g.fsf@gitster.siamese.dyndns.org> ``` On Thursday 29 November 2007, Junio C Hamano wrote: > Nicolas Pitre writes: > > ... In all the tutorials for $job I've done so > > far, I simply never talk about pull nor clone, but rather about init, > > "git remote", fetch and merge, with explicit and meaningful branch > > names. I think that basic commands, even if there is a bit more of > > them, make Git easier to learn and understand than talking about those > > magic meta commands hiding the truth away. > > That's actually a quite interesting approach for teaching. > > The original "tutorial" (now core-tutorial) was similar in spirit; it > built the user experience by starting at sequence of low level commands, > and then finally said "since this is so often used combination, there is > a short-hand for it that does all". I think the approach would work > quite well for people who want to use the tool with deep understanding. > > However, I am not so sure about people who just want canned set of > instructions and follow them blindly to get their work done. And I do > not think the latter classes of users are necessarily wrong. > > Such a canned set of instructions would (if the project that supplies > the cheat-sheet encourages merges instead of rebases) talk about "clone > then commit then push then pull and repeat", without mentioning what > pull does is fetch+merge nor what fetch means and what merge means, and > that would let people get started without deeper understanding. > > But the lack of deeper understanding would hurt them in the longer run > (e.g. "my push was rejected with something called non-fast-forward --- > what does that mean and what would I do now?"). What about ending the cheat-sheet with a big fat link to a FAQ? The FAQ answers common questions like the above (resulting from the cheat-sheet glossing over the details) with links to appropriate sections in the more thorough introduction (core-tutorial), explaining what's _really_ going on. Just a thought. Have fun! :) ...Johan -- Johan Herland, www.herland.net ``` ## Nicolas Pitre, 2007-11-29 17:47 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.99999.0711291236260.9605%40xanadu.home In-Reply-To: <7vlk8hzx0g.fsf@gitster.siamese.dyndns.org> ``` On Wed, 28 Nov 2007, Junio C Hamano wrote: > Nicolas Pitre writes: > > > ... In all the tutorials for $job I've done so > > far, I simply never talk about pull nor clone, but rather about init, > > "git remote", fetch and merge, with explicit and meaningful branch > > names. I think that basic commands, even if there is a bit more of > > them, make Git easier to learn and understand than talking about those > > magic meta commands hiding the truth away. > > That's actually a quite interesting approach for teaching. > > The original "tutorial" (now core-tutorial) was similar in spirit; it > built the user experience by starting at sequence of low level commands, > and then finally said "since this is so often used combination, there is > a short-hand for it that does all". I think the approach would work > quite well for people who want to use the tool with deep understanding. > > However, I am not so sure about people who just want canned set of > instructions and follow them blindly to get their work done. And I do > not think the latter classes of users are necessarily wrong. > > Such a canned set of instructions would (if the project that supplies > the cheat-sheet encourages merges instead of rebases) talk about "clone > then commit then push then pull and repeat", without mentioning what > pull does is fetch+merge nor what fetch means and what merge means, and > that would let people get started without deeper understanding. Sure. However the people for whom I produced the cheat-sheet have to deal with the repo I maintain, which has multiple branches already, and using an explicit "git remote add" allows for better names than the default "origin". Right there they become aware of the easy branching possibilities of Git. And with a constantly rewritten history in that repo, they have to rebase after every fetch and there is no released Git version with a short-hand for fetch+rebase. Nicolas ```