On 2/18/11 12:56 AM, Nils Adermann wrote:
After a discussion of various Git related problems/questions/best
practices Bernhard asked me to write up my concerns about the current
Symfony development process. I didn't feel strong enough about any of
these to bring them up before. Namely the problem I see is an unhealthy
amount of history re-writing with rebase. The problems I believe will
result from this are:
- Squashed commits are too big to identify individual changes and the
reason behind making them. Once Symfony2 in maintenance mode this will
make it more difficult to understand why a buggy piece of code was
written the way it was.
- Rebased pull requests lose information about branches that existed
during their development, resulting in commits with broken code and
failing tests. Such commits make tools like bisect difficult to use
because a problem may appear in multiple seemingly unrelated commits.
It really depends on how things are done. Sometimes, a pull request has
many commits that just fixes "stupid" typos and I don't see value in
keeping them in the final history.
Anyway, if you have a look at my repo, you will see that I squash less
and less. And for "lieutenants" (like Bernhard and Johannes), I mainly
review the code and then merge it as is without changing anything.
- Squashing commits of multiple authors drops authorship information,
since a commit can only ever have one commiter and one author. Having
our names listed as contributors is one of the few rewards for
contributing, so losing this information can come us a disappointment.
It has never happened. Nobody ever loosed authorship. I'm very picky on
this one. I bet you cannot find a single example in Symfony?
In general I would like to ask for commits to be more atomic, changing
one thing rather than many to allow for easier identification of change
origins once Symfony is in its maintenance cycle. The commits which
contained bugs and problems which were deleted through rebasing might
have helped us avoid making the same mistakes again when we later return
to fix a bug. And don't get me wrong, if you add a new feature in a
commit, it can still be significantly bigger than a bug fix commit.
agree
How this is handled is mostly up to Fabien, so I'm wondering if you
would consider changing your workflow? I realise that the current system
seems to work well for you, but I do expect it to cause problems in the
future.
Well, I think the workflow works well for people who know how to use Git:
* One pull request per problem/feature
* Atomic messages
* Good/standardized messages
* Clean history (as many commits as you want but sensible ones)
Right now, I'm very understanding with pull requests. But I can enforce
the rules more often. In that case, I can tell you that more than half
of the pull requests will need some kind of rework from their author.
Fabien
Nils
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
