www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Please don't rebase / ff the git master branches

reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
This post is regarding this discussion in the mailing list, to 
which I currently can't post:

http://forum.dlang.org/post/20131115141721.GR30523 llucax.com.ar

There appears to be an unanimous opinion that GitHub should allow 
merging pull requests by rebasing them onto master, and 
fast-forwarding the branch to the last commit in the pull. IMO, 
this is a bad idea!

Currently, the merge commits provide important information: which 
commits belong in which pull request, who merged the pull request 
and when. I realize that merges visually clutter the history in 
most git clients, however IMO the solution is not to drop that 
information on the floor, but rather improve the clients to 
present the history better.

As I understood, it has also been suggested to instead rewrite 
the commits in the pull request to include new information 
(changing the commit's "committer" field). This is also bad, 
because it will change the commit hash - and then, once the pull 
is merged, suddenly the pull author's branch contains different 
(though similar) commits than what's in master. If someone were 
to attempt to merge the two, what used to be a fast-forward will 
become a confusing mess.

For an example of what the merge commits are useful for: I've 
begun sketching a tool to automatically bisect D's history. And, 
I don't mean DMD's history: I mean the history of D + Phobos + 
Druntime. Since changes are often done to two or three projects 
simultaneously, and one won't work without the other, it is often 
difficult to run a git bisect on just one project, as it will 
break sooner or later in the repo's history, as the other D 
components become incompatible. While you can't really sensibly 
merge three DAGs chronologically, it's easy to merge three sorted 
lists (three linear histories). Git repositories do not have 
linear histories, but the pull request merge history does! Thus, 
it's practical only if you consider pull request merges.
Nov 15 2013
next sibling parent reply "qznc" <qznc web.de> writes:
On Friday, 15 November 2013 at 22:36:14 UTC, Vladimir Panteleev
wrote:
 This post is regarding this discussion in the mailing list, to 
 which I currently can't post:

 http://forum.dlang.org/post/20131115141721.GR30523 llucax.com.ar

 There appears to be an unanimous opinion that GitHub should 
 allow merging pull requests by rebasing them onto master, and 
 fast-forwarding the branch to the last commit in the pull. IMO, 
 this is a bad idea!

 Currently, the merge commits provide important information: 
 which commits belong in which pull request, who merged the pull 
 request and when. I realize that merges visually clutter the 
 history in most git clients, however IMO the solution is not to 
 drop that information on the floor, but rather improve the 
 clients to present the history better.

 As I understood, it has also been suggested to instead rewrite 
 the commits in the pull request to include new information 
 (changing the commit's "committer" field). This is also bad, 
 because it will change the commit hash - and then, once the 
 pull is merged, suddenly the pull author's branch contains 
 different (though similar) commits than what's in master. If 
 someone were to attempt to merge the two, what used to be a 
 fast-forward will become a confusing mess.

 For an example of what the merge commits are useful for: I've 
 begun sketching a tool to automatically bisect D's history. 
 And, I don't mean DMD's history: I mean the history of D + 
 Phobos + Druntime. Since changes are often done to two or three 
 projects simultaneously, and one won't work without the other, 
 it is often difficult to run a git bisect on just one project, 
 as it will break sooner or later in the repo's history, as the 
 other D components become incompatible. While you can't really 
 sensibly merge three DAGs chronologically, it's easy to merge 
 three sorted lists (three linear histories). Git repositories 
 do not have linear histories, but the pull request merge 
 history does! Thus, it's practical only if you consider pull 
 request merges.
Yay, another war about git workflows. :) It is sad that D history cannot be nicely tracked, because it is split into three repositories without git having a clue about dependencies between them. At work we have a C compiler frontend [0] and a backend [1] in different repos. The frontend includes the backend as a git submodule. Therefore the frontend always uses a specific revision of the backend. Bisecting is trivial now. Faulty commits to the backend cannot not break the frontend, because it still points to a previous revision. [0] http://pp.info.uni-karlsruhe.de/git/cparser/ [1] http://pp.info.uni-karlsruhe.de/git/libFirm/
Nov 15 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 15, 2013 at 11:51:03PM +0100, qznc wrote:
[...]
 It is sad that D history cannot be nicely tracked, because it is
 split into three repositories without git having a clue about
 dependencies between them.
 
 At work we have a C compiler frontend [0] and a backend [1] in
 different repos. The frontend includes the backend as a git
 submodule. Therefore the frontend always uses a specific revision
 of the backend. Bisecting is trivial now. Faulty commits to the
 backend cannot not break the frontend, because it still points to
 a previous revision.
[...] Yeah, I ran into this propblem too. Since druntime/phobos changes quite often depend on new compiler features, this means that you can't effectively git bisect bugs that go back more than a few months ago, since druntime/phobos will stop compiling. I've been working around this (imperfectly) by checking out druntime/phobos by approximate dates of the current dmd version being bisected, but the result from this kind of bisection is on shaky ground since it may not represent the actual state of things at that particular juncture (it may not even represent any actual combination of dmd/druntime/phobos that was actually in use at any time!). Maybe we should incorporate druntime/phobos as submodules in the dmd repos? This will greatly help in tracking down regressions with git bisect (I remember there were a few that I couldn't track down because of the difficulty of finding the correct druntime/phobos versions needed for a particular version of dmd). This will also give us a much better history of D development. T -- This is not a sentence.
Nov 15 2013
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 15 November 2013 at 23:07:46 UTC, H. S. Teoh wrote:
 Maybe we should incorporate druntime/phobos as submodules in 
 the dmd repos?
My plan for the bisect tool is to build a D.git repo, with a linear history, which contains DMD, Druntime and Phobos as subprojects.
Nov 15 2013
prev sibling parent "qznc" <qznc web.de> writes:
On Friday, 15 November 2013 at 23:07:46 UTC, H. S. Teoh wrote:
 Maybe we should incorporate druntime/phobos as submodules in 
 the dmd
 repos? This will greatly help in tracking down regressions with 
 git
 bisect (I remember there were a few that I couldn't track down 
 because
 of the difficulty of finding the correct druntime/phobos 
 versions needed
 for a particular version of dmd). This will also give us a much 
 better
 history of D development.
If this is seriously considered, then we should also look at git subtree. It is similar to submodules, but with different tradeoffs. When we introduced our submodules-solution, subtree did not exist yet.
Nov 15 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2013-11-15 at 23:51 +0100, qznc wrote:
[…]
 Yay, another war about git workflows. :)
[…] I always thought it was de rigueur never to rebase a publicly published repository. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Nov 16 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-16 13:47, Russel Winder wrote:

 I always thought it was de rigueur never to rebase a publicly published
 repository.
I think the idea is to rebase the topic branch. Make sure all new changes to master comes first, then the changes to the topic branch. Usually it's perfectly fine to rebase topic branches and other temporary branches. You might want to be careful if you're collaborating with someone else on that branch. -- /Jacob Carlborg
Nov 17 2013
parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2013-11-18 at 08:57 +0100, Jacob Carlborg wrote:
 On 2013-11-16 13:47, Russel Winder wrote:
 
 I always thought it was de rigueur never to rebase a publicly published
 repository.
I think the idea is to rebase the topic branch. Make sure all new changes to master comes first, then the changes to the topic branch.
As a technique for merging in a feature branch to the mainline with Git, this can work – the problem is dealing with reverse merges caused reordering, but if this history revisionism is allowed then fine. Mercurail is a different situation, but is not relevant here.
 Usually it's perfectly fine to rebase topic branches and other temporary 
 branches. You might want to be careful if you're collaborating with 
 someone else on that branch.
I think we are agreeing and saying the same thing really, once a branch or tag is made public it shouldn't be rebased. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Nov 18 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-11-18 14:05, Russel Winder wrote:

 I think we are agreeing and saying the same thing really, once a branch
 or tag is made public it shouldn't be rebased.
I'm saying that even if a branch is made public it's ok to rebase. This happens all the time for pull requests. The important thing here is that the branches are temporary. They are removed after they've been merged to master. -- /Jacob Carlborg
Nov 18 2013
prev sibling parent "Martin Nowak" <code dawg.eu> writes:
On Friday, 15 November 2013 at 22:36:14 UTC, Vladimir Panteleev 
wrote:
 Currently, the merge commits provide important information: 
 which commits belong in which pull request, who merged the pull 
 request and when. I realize that merges visually clutter the 
 history in most git clients, however IMO the solution is not to 
 drop that information on the floor, but rather improve the 
 clients to present the history better.
I posted just about the same on dmd-internals. http://forum.dlang.org/post/ef31074b-10cb-4b23-8e38-5f4be1667eef email.android.com
Nov 16 2013