2014-11-07 15:55 GMT+01:00 Tomas Heinrich <[email protected]>: > On 11/07/14 12:27, Rainer Gerhards wrote: > >> Hi all, >> > > Hello Rainer, > > based on recent discussion ([1] is a good entry point), it looks like >> there >> is consensus that feature-branch commits shall be squashed before merging >> them into master. >> > > Before implementing such a change, please give it some more time for > people to comment and think it through. This is a big change and shouldn't > be rushed. > > Thanks. I had the (obviously wrong) idea that no voices meant people were happy with it -- especially as that other thread received a lot of comments initially. But probably most folks got bored when it got longer and longer (understandable now that I think about it), so this probably didn't mean many are fine with the direction. My bad not to think about this.
I'll post another pending policy change from that thread (not yet finalized), but I'll do that with a fresh posting so that it doesn't get buried in this thread ;) This is a bit bad for me because in almost all cases I >> like the ability to see the interim steps that lead to a feature in >> question (for bisect, but also to better understand what was going on). I >> have also discussed this with my peers in Adiscon and they also prefer the >> way it currently is. >> > > I think it's better to have changes split up into smaller cohesive chunks > (that also don't break compilation, functionality, are well documented in > the commit message and are generally "tidied up"). > Having the history more granular helps understanding why what happened > where - I personally do that _a lot_. Squashing makes for tidier history > but also obfuscates it. That's my prime concern. > Having smaller commits makes reverting changes easier. > > That said, I also do a lot of git-blame-ing and getting through the thick > graph of merges isn't fun either. > more on that in the upcoming thread (not necessarily today, have some appointments soon). > > To satisfy both requirements, we have now setup an internal git for >> Adiscon >> use. Our plan is to have a parallel adiscon-master branch inside that >> repo, >> which will contain every detail. Its master branch will mirror the public >> git and contain squashed commits. >> > > Please don't. :] > Having multiple branches with the same content but different histories > would bring confusion; directly or indirectly. > We now have contributions from Adiscon (including me) and others. Those >> from Adiscon will be done in feature branches, with detail commits and be >> merged into the adiscon-master branch (so that it contains all details). >> Then, I will squash the feature branch into a single commit and merge that >> into master. So far, so good. >> > > But now we also have non-Adiscon contributions. A current example is [2]. >> One question is if they must be squashed as well? >> > > As Brian similarly noted in a previous email, I don't think it's a good > idea to squash on the receiving side. > I edit and rebase commits all the time before submitting them for > inclusion. If I've dissected the change into couple of patches, It's > because I think there's a reason for it. If we'll decide to make it a > policy to squash everything before inclusion, I'll send a single patch - no > need for upstream to do that. > > Yeah, that was along the lines that we used successfully for many years. I appreciate that extra information as it helps me understand what's going on (thus at least I don't wanted to loose it). From that other thread, I got the strong impression that features requiring more than one commit are no longer preferred. I have this luxury of rewriting my changes because I work in a private > branch. Since you push your changes early and often, rebasing (editing, > squashing) might be problematic - unless it is made a policy that there are > no guaranties about what happens in a feature branch. > Well, I now also have the Adiscon private repository and e.g. the testbench changes are now only in there (it was my testbed to see which problems come up with that approach). But I've already seen how this affects my workflow, as I am no longer able to point people to the code as it develops (there was a concrete case yesterday with a broken testbench test). So far, I tried to do everything in public and not be ashamed of the sometimes dumb errors I made and that manifest in git history. I admit that I make "trivial" changes directly to master and every now and then (seldom, but happend), I screwed up and got master to fail building. Not sure, though, if that would have been any better if I create a new branch, apply change, merge new branch, delete it - all within 5 minutes. This sounds a little bit overboard to me. >From what I got in this thread it looks like more people are in favor of granular commits than the fat ones. I am still listening to voices, but giving the current state, I won't change the way I do commits. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
