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=


al

 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=


his

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


fe

 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=


e:

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




e'

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




ocal

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




es,

 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. :)
=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 =


by

 using the merge button that github provides, so most merges are done =


doing

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


ay

 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=


ly

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


to

 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 =


much

 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 "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 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
next sibling parent reply 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
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 parent reply 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
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 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 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 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
 


Obviously 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
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


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


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


 Obviously 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


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