www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Request for D core devs: git pull --rebase

reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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=

 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*. T=

 helps keep history clean and easier to navigate, making everyone's li=

 that much easier. :)
=20
 For example:
=20
 $ git commit -m "my local stuff"
 $ git pull --rebase origin master
 $ git push origin master

I 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
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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=

 Hi folks!
=20
 This is a friendly request for D core devs to use 'git pull --rebas=


 instead of just plain 'git pull' when pulling remote changes into l=


 repositories. The reason for this is that it takes any outstanding
 commits in your local tree, unrolls them, pulls in the remote chang=


 and reapplies your local commits *without creating a merge commit*.=


 helps keep history clean and easier to navigate, making everyone's =


 that much easier. :)
=20
 For example:
=20
 $ git commit -m "my local stuff"
 $ git pull --rebase origin master
 $ git push origin master

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 =

 whatever that does. Doing anything else is more work. That's not to s=

 that 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=

 causes issues), then the Phobos devs are almost certainly just going =

 continue 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 =

 more 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
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 06-11-2011 02:37, Jesse Phillips wrote:
 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 Davis

My 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.

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. - Alex
Nov 06 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
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
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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:

 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.

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. - Alex
Nov 06 2011
prev sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 06-11-2011 19:41, Jesse Phillips wrote:
 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.

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. - Alex
Nov 06 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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
prev sibling next sibling parent reply Jesse Phillips <jessekphillips+d gmail.com> writes:
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 Davis

My 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
parent Kagamin <spam here.lot> writes:
Jesse Phillips Wrote:

 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 Davis

My 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.

Well... if they're intermixed in time then they should be shown as such.
 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
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, November 06, 2011 01:37:52 Jesse Phillips wrote:
 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 Davis

My 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.

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 Davis
Nov 05 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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
prev sibling next sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
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 master
 

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
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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:

 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

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.

I think it seems generally accepted that the D NGs are just misleadingly named.
Nov 06 2011
prev sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 06-11-2011 05:40, Steve Teale wrote:
 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 master

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

I agree with you. Given the lack of such a group, this seemed like the most sensible place to post this. - Alex
Nov 06 2011
prev sibling next sibling parent Jesse Phillips <jessekphillips+d gmail.com> writes:
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
prev sibling parent Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
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!

 - Alex

This 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