I'm in favor of the process being as simple as possible. The more work and
thought that has to be put into dealing with pull requests, the more likely
either work will get slowed down, or someone will make a mistake.
I feel like if I want to squash, etc I can just do that on branches on my
own fork, and then send the cleaned up version back to you. I don't feel
like you should have to deal with squashing my commits. I also don't have
a problem personally with seeing the merge messages.
I think that the patch creator (in the feature branch) should do whatever
squashing, rebaseing, etc is desired before the patch is sent upstream.
If it's a small change, it may make sense to go ahead and alter the history
before it's merged, but this shouldn't be a matter of "make it one branch", but
rather "with 20-20 hindsight, this is the ideal series of patches to implement
this feature" where you trim out false starts, bugs that you later fix, etc.
Especially if there is a large change, it's valuable to see the steps in the
change individually rather than just having everything combined into one massive
patch.
David Lang
On Fri, Nov 7, 2014 at 6:39 AM, Rainer Gerhards <[email protected]>
wrote:
2014-11-07 12:35 GMT+01:00 singh.janmejay <[email protected]>:
Rainer,
Do we really need to squash? Why not just keep it simple and merge
changes
as they come? Its so much better for looking at exactly how/why things
are
the way they are.
No rebase, no rewrites of history etc, just the simple commit and merge.
well, I don't need all of that overhead. But from the other thread it
looked like folks wanted it and nobody said anything else...
Rainer
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assist technology.
On Nov 7, 2014 4:57 PM, "Rainer Gerhards" <[email protected]>
wrote:
Hi all,
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. 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.
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.
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? Let's assume this is
not
the case for whatever reason. So I merge them directly into master.
Then,
to keep my actual working tree up to date, I need to cherry-pick them
into
adiscon-master. This is where I am a bit hesitant, because of the
manual
action. I fear that the master and adiscon-master branches may begin to
diverge, and be it through a simple mistake.
So maybe it is better to merge pull requests into new feature branches,
and
then work "as usual": merge feature branch into adiscon-master, squash
feature branch, then merge it as single commit into master.
To sum up: I would like to have two branches, the private one with all
detail information, the public one minus those commits that are
considered
distracting. What is the best way to achieve this goal?
Feedback appreciated,
Rainer
[1]
http://lists.adiscon.net/pipermail/rsyslog/2014-November/038883.html
[2] https://github.com/rsyslog/rsyslog/pull/147
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
