digitalmars.D - Request for D core devs: git pull --rebase
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (14/14) Nov 05 2011 Hi folks!
- Jonathan M Davis (22/37) Nov 05 2011 ,
- Jonathan M Davis (19/46) Nov 05 2011 e'
- Vladimir Panteleev (10/13) Nov 05 2011 It also makes the history easier to follow (less branching in the DAG).
- Jesse Phillips (15/20) Nov 05 2011 My quick search:
- Jonathan M Davis (16/41) Nov 05 2011 Rebasing, I understand. Rebasing happens often enough in pull requests. ...
- Vladimir Panteleev (8/10) Nov 05 2011 It's a bit more involved than that (in a good way). Each commit has an
- Jesse Phillips (7/11) Nov 06 2011 I agree it probably isn't a big deal, but it _is_ a rewrite and _does_
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (6/17) Nov 06 2011 I should clarify that this entire post was directed at *normal git pull
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (5/25) Nov 06 2011 Rewriting history in forks is perfectly fine. In fact, many people
- Michel Fortin (17/20) Nov 06 2011 Rewriting history in private forks is perfectly fine. Doing so in
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (5/22) Nov 06 2011 Right, agreed. I generally go by the logic that any of my forks
- Kagamin (3/24) Nov 07 2011 In fact, speaking about Don's CTFE fixes, they're merged repeatedly from...
- Steve Teale (7/23) Nov 05 2011 Obviously I'm in a grumpy mood today, but isn't all this VCS stuff
- Nick Sabalausky (4/26) Nov 06 2011 I think it seems generally accepted that the D NGs are just misleadingly...
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (4/27) Nov 06 2011 I agree with you. Given the lack of such a group, this seemed like the
- Johann MacDonagh (9/23) Nov 06 2011 This only applies to people to push to master, and I think Walter is the...
Hi folks! This is a friendly request for D core devs to use 'git pull --rebase' instead of just plain 'git pull' when pulling remote changes into local repositories. The reason for this is that it takes any outstanding commits in your local tree, unrolls them, pulls in the remote changes, and reapplies your local commits *without creating a merge commit*. This helps keep history clean and easier to navigate, making everyone's life that much easier. :) For example: $ git commit -m "my local stuff" $ git pull --rebase origin master $ git push origin master Thanks! - Alex
Nov 05 2011
On Saturday, November 05, 2011 22:38:03 Alex R=C3=B8nne Petersen wrote:=Hi folks! =20 This is a friendly request for D core devs to use 'git pull --rebase'=instead of just plain 'git pull' when pulling remote changes into loc=alrepositories. The reason for this is that it takes any outstanding commits in your local tree, unrolls them, pulls in the remote changes=,and reapplies your local commits *without creating a merge commit*. T=hishelps keep history clean and easier to navigate, making everyone's li=fethat much easier. :) =20 For example: =20 $ git commit -m "my local stuff" $ git pull --rebase origin master $ git push origin masterI would point out that for druntime and Phobos, most merging is done by= using=20 the merge button that github provides, so most merges are done doing wh= atever=20 that does. Doing anything else is more work. That's not to say that the= re=20 isn't value in it, but unless the result is considerably negative (and = I don't=20 see why a stray extra commit for the merge really causes issues), then = the=20 Phobos devs are almost certainly just going to continue to use the merg= e=20 button, because it's less work for them. For dmd, I don't know what Walter does exactly. I think that he does mu= ch more=20 by hand, so that process is likely quite different. - Jonathan M Davis
Nov 05 2011
On Saturday, November 05, 2011 15:10:52 Jonathan M Davis wrote:On Saturday, November 05, 2011 22:38:03 Alex R=C3=B8nne Petersen wrot=e:e'Hi folks! =20 This is a friendly request for D core devs to use 'git pull --rebas=ocalinstead of just plain 'git pull' when pulling remote changes into l=es,repositories. The reason for this is that it takes any outstanding commits in your local tree, unrolls them, pulls in the remote chang=Thisand reapplies your local commits *without creating a merge commit*.=lifehelps keep history clean and easier to navigate, making everyone's =bythat much easier. :) =20 For example: =20 $ git commit -m "my local stuff" $ git pull --rebase origin master $ git push origin master=20 I would point out that for druntime and Phobos, most merging is done =using the merge button that github provides, so most merges are done =doingwhatever that does. Doing anything else is more work. That's not to s=aythat there isn't value in it, but unless the result is considerably negative (and I don't see why a stray extra commit for the merge real=lycauses issues), then the Phobos devs are almost certainly just going =tocontinue to use the merge button, because it's less work for them. =20 For dmd, I don't know what Walter does exactly. I think that he does =muchmore by hand, so that process is likely quite different.So, I should probably add the question more explicitly, what exactly do= es=20 using --rebase gain other than not having the extra commit message? Why= is it=20 better? - Jonathan M Davis
Nov 05 2011
On Sun, 06 Nov 2011 00:15:37 +0200, Jonathan M Davis <jmdavisProg gmx.com> wrote:So, I should probably add the question more explicitly, what exactly does using --rebase gain other than not having the extra commit message? Why is it better?It also makes the history easier to follow (less branching in the DAG). I'm personally reserved about this advice, mainly because handling conflicts is more complicated. D contributors who are not confident in their Git skills may want to avoid this, since it's easy to make a mistake and get into a situation that's not trivial or obvious how to recover from. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Nov 05 2011
On Sat, 05 Nov 2011 15:15:37 -0700, Jonathan M Davis wrote:So, I should probably add the question more explicitly, what exactly does using --rebase gain other than not having the extra commit message? Why is it better? - Jonathan M DavisMy quick search: http://book.git-scm.com/4_rebasing.html Suggests that it will recreate all the changes at the point of merge rather than having a commit with two parents. This would mean the history shows all changes of a branch at the point of merge rather intermixed based on date. One downside to this is that it is a form of history rewrite. And if I understand how git works, this means that the branch in SomeOnes repository will not correspond to any commits in the rebased master. Meaning pulling the latest Phobos into said branch wouldn't work. Usually after a merge the branch would be dead anyway. I don't know if it is done elsewhere but the general rule is not to rewrite history in a published repository, this would be doing just that, so I would not recommend it.
Nov 05 2011
On Sunday, November 06, 2011 01:37:52 Jesse Phillips wrote:On Sat, 05 Nov 2011 15:15:37 -0700, Jonathan M Davis wrote:Rebasing, I understand. Rebasing happens often enough in pull requests. It affects branches that way, not master, so I don't think that it's really all that big a deal - particularly when such branchs frequently created just for that pull request and are deleted aftewards. It's rebasing master in the main repository that definitely should _never_ happen without a _very_, _very_, _very_ good reason. However, what the OP is looking for specifically, is that a rebase be done when merging into the main repository, and I don't see what the real benefit of that is. The commits lose their original date and are no longer interspersed, which could be good or bad, depending on what you're looking for. It gets rid of the extra commit for the merge, which is nice, but not worth the extra effort of doing the merge manually IMHO. So, while I understand rebasing, I don't understand why the OP thinks that using --rebase with merge is such an improvement. - Jonathan M DavisSo, I should probably add the question more explicitly, what exactly does using --rebase gain other than not having the extra commit message? Why is it better? - Jonathan M DavisMy quick search: http://book.git-scm.com/4_rebasing.html Suggests that it will recreate all the changes at the point of merge rather than having a commit with two parents. This would mean the history shows all changes of a branch at the point of merge rather intermixed based on date. One downside to this is that it is a form of history rewrite. And if I understand how git works, this means that the branch in SomeOnes repository will not correspond to any commits in the rebased master. Meaning pulling the latest Phobos into said branch wouldn't work. Usually after a merge the branch would be dead anyway. I don't know if it is done elsewhere but the general rule is not to rewrite history in a published repository, this would be doing just that, so I would not recommend it.
Nov 05 2011
On Sun, 06 Nov 2011 04:16:01 +0200, Jonathan M Davis <jmdavisProg gmx.com> wrote:The commits lose their original date and are no longer interspersed, which could be good or bad, depending on what you're looking for.It's a bit more involved than that (in a good way). Each commit has an author date and a commit date - when rewriting history, author dates are almost always preserved. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Nov 05 2011
On Sat, 05 Nov 2011 19:16:01 -0700, Jonathan M Davis wrote:Rebasing, I understand. Rebasing happens often enough in pull requests. It affects branches that way, not master, so I don't think that it's really all that big a deal - particularly when such branchs frequently created just for that pull request and are deleted aftewards.I agree it probably isn't a big deal, but it _is_ a rewrite and _does_ have some implications. If you merge with --rebase, that branch is _dead_. As pull requests are public this could cause confusion, but mostly it should be something to be aware of. It maybe reasonable, but as you say, why do it if you don't get to use the merge button.
Nov 06 2011
On 06-11-2011 19:41, Jesse Phillips wrote:On Sat, 05 Nov 2011 19:16:01 -0700, Jonathan M Davis wrote:I should clarify that this entire post was directed at *normal git pull operations*. Not merging of pull requests. Those will (and should!) result in a merge commit to make it easier to see when in history a pull request was merged in. - AlexRebasing, I understand. Rebasing happens often enough in pull requests. It affects branches that way, not master, so I don't think that it's really all that big a deal - particularly when such branchs frequently created just for that pull request and are deleted aftewards.I agree it probably isn't a big deal, but it _is_ a rewrite and _does_ have some implications. If you merge with --rebase, that branch is _dead_. As pull requests are public this could cause confusion, but mostly it should be something to be aware of. It maybe reasonable, but as you say, why do it if you don't get to use the merge button.
Nov 06 2011
On 06-11-2011 02:37, Jesse Phillips wrote:On Sat, 05 Nov 2011 15:15:37 -0700, Jonathan M Davis wrote:Rewriting history in forks is perfectly fine. In fact, many people generally consider it polite for contributors to clean up their history using rebase before sending changes upstream. - AlexSo, I should probably add the question more explicitly, what exactly does using --rebase gain other than not having the extra commit message? Why is it better? - Jonathan M DavisMy quick search: http://book.git-scm.com/4_rebasing.html Suggests that it will recreate all the changes at the point of merge rather than having a commit with two parents. This would mean the history shows all changes of a branch at the point of merge rather intermixed based on date. One downside to this is that it is a form of history rewrite. And if I understand how git works, this means that the branch in SomeOnes repository will not correspond to any commits in the rebased master. Meaning pulling the latest Phobos into said branch wouldn't work. Usually after a merge the branch would be dead anyway. I don't know if it is done elsewhere but the general rule is not to rewrite history in a published repository, this would be doing just that, so I would not recommend it.
Nov 06 2011
On 2011-11-06 12:16:41 +0000, Alex Rønne Petersen <xtzgzorex gmail.com> said:Rewriting history in forks is perfectly fine. In fact, many people generally consider it polite for contributors to clean up their history using rebase before sending changes upstream.Rewriting history in private forks is perfectly fine. Doing so in public forks can be somewhat troublesome. If someone finds a bug in your fork and propose a patch for it you're going to have some fun merging if you've also rewritten history meanwhile. For instance, this pull request to a topic branch of my forked DMD repository fixed an issue with one of my DMD pull requests: <https://github.com/michelf/dmd/pull/1>. Had I rewritten history while Daniel was preparing this pull request to my topic branch, merging would have to be done manually. I'm not saying rebasing shouldn't be done -- it certainly produces a cleaner result -- but we should keep in mind that it can make collaboration on topic branches harder. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Nov 06 2011
On 06-11-2011 16:01, Michel Fortin wrote:On 2011-11-06 12:16:41 +0000, Alex Rønne Petersen <xtzgzorex gmail.com> said:Right, agreed. I generally go by the logic that any of my forks shouldn't be considered 'stable' targets as far as VCS history goes, but this is all a matter of personal opinion/policy. - AlexRewriting history in forks is perfectly fine. In fact, many people generally consider it polite for contributors to clean up their history using rebase before sending changes upstream.Rewriting history in private forks is perfectly fine. Doing so in public forks can be somewhat troublesome. If someone finds a bug in your fork and propose a patch for it you're going to have some fun merging if you've also rewritten history meanwhile. For instance, this pull request to a topic branch of my forked DMD repository fixed an issue with one of my DMD pull requests: <https://github.com/michelf/dmd/pull/1>. Had I rewritten history while Daniel was preparing this pull request to my topic branch, merging would have to be done manually. I'm not saying rebasing shouldn't be done -- it certainly produces a cleaner result -- but we should keep in mind that it can make collaboration on topic branches harder.
Nov 06 2011
Jesse Phillips Wrote:On Sat, 05 Nov 2011 15:15:37 -0700, Jonathan M Davis wrote:Well... if they're intermixed in time then they should be shown as such.So, I should probably add the question more explicitly, what exactly does using --rebase gain other than not having the extra commit message? Why is it better? - Jonathan M DavisMy quick search: http://book.git-scm.com/4_rebasing.html Suggests that it will recreate all the changes at the point of merge rather than having a commit with two parents. This would mean the history shows all changes of a branch at the point of merge rather intermixed based on date.One downside to this is that it is a form of history rewrite. And if I understand how git works, this means that the branch in SomeOnes repository will not correspond to any commits in the rebased master. Meaning pulling the latest Phobos into said branch wouldn't work. Usually after a merge the branch would be dead anyway.In fact, speaking about Don's CTFE fixes, they're merged repeatedly from this branch https://github.com/donc/dmd/commits/ctfeclass which is quite long lasting.
Nov 07 2011
On Sat, 05 Nov 2011 22:38:03 +0100, Alex Rønne Petersen wrote:Hi folks! This is a friendly request for D core devs to use 'git pull --rebase' instead of just plain 'git pull' when pulling remote changes into local repositories. The reason for this is that it takes any outstanding commits in your local tree, unrolls them, pulls in the remote changes, and reapplies your local commits *without creating a merge commit*. This helps keep history clean and easier to navigate, making everyone's life that much easier. :) For example: $ git commit -m "my local stuff" $ git pull --rebase origin master $ git push origin masterObviously I'm in a grumpy mood today, but isn't all this VCS stuff somewhat off-topic? It certainly seems to be growing in volume. This is the digitalmars.D group. Seems that we need a digitalmars.D.process group as well. The first (long) posting might well be some kind of explanation of what the process is. Steve
Nov 05 2011
"Steve Teale" <steve.teale britseyeview.com> wrote in message news:j9533f$7oc$2 digitalmars.com...On Sat, 05 Nov 2011 22:38:03 +0100, Alex Rønne Petersen wrote:I think it seems generally accepted that the D NGs are just misleadingly named.Hi folks! This is a friendly request for D core devs to use 'git pull --rebase' instead of just plain 'git pull' when pulling remote changes into local repositories. The reason for this is that it takes any outstanding commits in your local tree, unrolls them, pulls in the remote changes, and reapplies your local commits *without creating a merge commit*. This helps keep history clean and easier to navigate, making everyone's life that much easier. :) For example: $ git commit -m "my local stuff" $ git pull --rebase origin master $ git push origin masterObviously I'm in a grumpy mood today, but isn't all this VCS stuff somewhat off-topic? It certainly seems to be growing in volume. This is the digitalmars.D group. Seems that we need a digitalmars.D.process group as well. The first (long) posting might well be some kind of explanation of what the process is.
Nov 06 2011
On 06-11-2011 05:40, Steve Teale wrote:On Sat, 05 Nov 2011 22:38:03 +0100, Alex Rønne Petersen wrote:I agree with you. Given the lack of such a group, this seemed like the most sensible place to post this. - AlexHi folks! This is a friendly request for D core devs to use 'git pull --rebase' instead of just plain 'git pull' when pulling remote changes into local repositories. The reason for this is that it takes any outstanding commits in your local tree, unrolls them, pulls in the remote changes, and reapplies your local commits *without creating a merge commit*. This helps keep history clean and easier to navigate, making everyone's life that much easier. :) For example: $ git commit -m "my local stuff" $ git pull --rebase origin master $ git push origin masterObviously I'm in a grumpy mood today, but isn't all this VCS stuff somewhat off-topic? It certainly seems to be growing in volume. This is the digitalmars.D group. Seems that we need a digitalmars.D.process group as well. The first (long) posting might well be some kind of explanation of what the process is. Steve
Nov 06 2011
On 11/5/2011 5:38 PM, Alex Rønne Petersen wrote:Hi folks! This is a friendly request for D core devs to use 'git pull --rebase' instead of just plain 'git pull' when pulling remote changes into local repositories. The reason for this is that it takes any outstanding commits in your local tree, unrolls them, pulls in the remote changes, and reapplies your local commits *without creating a merge commit*. This helps keep history clean and easier to navigate, making everyone's life that much easier. :) For example: $ git commit -m "my local stuff" $ git pull --rebase origin master $ git push origin master Thanks! - AlexThis only applies to people to push to master, and I think Walter is the only one who does that. In this case, I completely agree with you. Walter should either create a branch with a name that describes what he's doing, or rebase his local commits onto the remote master before pushing. We've already has a few problems with this, where some versions of Phobos have been tagged but weren't either merged or rebased successfully. I submitted pull requests to fix both of them.
Nov 06 2011