hasufell wrote:
> > A version bump plus cleaning up older ebuilds will be considered
> > one logical change, I suppose?
>
> I'd consider it two logical changes
..
> But I don't have a strong opinion on that
I do - I think this is really important. Having clean history makes a
huge difference for anyone who wants to use that history.
One argument against those clean professional development practices
that comes up over and over is that it takes more time, ("mimimi I
don't have time to be part of any solution") which is sometimes true
- but since git makes committing so easy usually the difference
isn't very big, and the payoff when you benefit in the future is
quite significant.
<rant>
Of course, lots of people still do not care at all about what is only
a potential benefit in an uncertain future. Personally I might prefer
that they stop doing open source instead of wasting my time with
their whining. You pay forward, that's the point.
</rant>
Getting back on track, it's likely that first-time git users will
have to get used to committing more often than with other VCSes.
> and I'm not sure if we can enforce commit rules in such
> fine-grained details, can we?
It's impossible to catch all cases, and there will always be
disagreement between individual developers as to what is actually
appropriate useful and correct. I think explicit consensus is
impractical. :\
> Do you think this should be added explicitly?
I think keeping rules vague is probably the only thing that somehow
scales.
I really don't know. I get a feeling that a given individual either
understands this concept of atomic changes, or they don't. I haven't
seen someone who at first didn't understand (with someone explaining
it to them of course) it come around and "get it" sometime later. :(
//Peter
