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.
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. 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.
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.
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.
Tomas
_______________________________________________
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.
