digitalmars.D - Please don't rebase / ff the git master branches
- Vladimir Panteleev (33/33) Nov 15 2013 This post is regarding this discussion in the mailing list, to
- qznc (14/48) Nov 15 2013 Yay, another war about git workflows. :)
- H. S. Teoh (22/32) Nov 15 2013 [...]
- Vladimir Panteleev (4/6) Nov 15 2013 My plan for the bisect tool is to build a D.git repo, with a
- qznc (5/16) Nov 15 2013 If this is seriously considered, then we should also look at git
- Russel Winder (11/12) Nov 16 2013 […]
- Jacob Carlborg (8/10) Nov 17 2013 I think the idea is to rebase the topic branch. Make sure all new
- Russel Winder (13/23) Nov 18 2013 As a technique for merging in a feature branch to the mainline with Git,
- Jacob Carlborg (7/9) Nov 18 2013 I'm saying that even if a branch is made public it's ok to rebase. This
- Martin Nowak (4/10) Nov 16 2013 I posted just about the same on dmd-internals.
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
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
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
"Vladimir Panteleev" <vladimir thecybershadow.net> 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
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
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
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
On Mon, 2013-11-18 at 08:57 +0100, Jacob Carlborg wrote:On 2013-11-16 13:47, Russel Winder wrote: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.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.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
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
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