Barosl just verified in chat that it makes an empty commit with the merge information even when rebasing.
I'm now pretty ambivalent towards this. I don't mind linear histories, but ... I can handle graphy ones too. -Manish Goregaokar On Fri, Oct 16, 2015 at 2:08 AM, Manish Goregaokar <manishsm...@gmail.com> wrote: > I like having a linear history, but I still want the merge commit (you can > have fast forward merge commits which have a single parent) with the PR and > reviewer info. We should check that we still get that. > > I've not actually had trouble with nonlinear history -- traversal is easy > and that's mostly what I've had to do. > > I've found the merge commit very important when trawling through rustc > history, though. > > > Makes it harder to distinguish which commits go together, everything is > linear so there are no "commits groups" anymore. > > Note that commit parents still work. `git log --topo-order` iirc does > bunching of commits by parent chains (verses `git log --date-order`, which > I *think* is the default). > > > > -Manish Goregaokar > > On Thu, Oct 15, 2015 at 7:17 PM, Anthony Ramine <n.ox...@gmail.com> wrote: > >> Le 15 oct. 2015 à 14:42, Lars Bergstrom <larsb...@mozilla.com> a écrit : >> >> > - Automatic rebasing >> > >> > Right now, our commit log history is somewhat mumbly-jumbly. The >> autolander adds a commit for the pull request detailing who reviewed it, >> etc., but the commit itself sits in the history wherever `master` was on >> the commiter’s local machine when they did the work. This makes looking at >> a given commit and figuring which PR it landed in require either some extra >> tooling or git-fu that most users don’t have. >> >> I'm against this for the following reasons: >> >> - Makes it harder to distinguish which commits go together, everything is >> linear so there are no "commits groups" anymore. >> >> - Makes it harder to bisect, we can't distinguish branch tips easily >> anymore, so we can't skip internal commits easily when bisecting. Tests >> aren't run on commits that were not branch tips, so bisecting could fail >> for whatever reason at every step. >> >> - Makes it harder to see which local branches were merged through git >> branch --merged (and similar commands) because all commits are now >> cherry-picked by Homu. >> >> In general, I don't even buy the argument that "merges make the log >> unreadable". >> >> _______________________________________________ >> dev-servo mailing list >> dev-servo@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-servo >> > > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo