Re: How does team maintenace of python module works?
On Thursday, February 21, 2013 02:02:09 PM Chow Loong Jin wrote:
> On 21/02/2013 12:46, Barry Warsaw wrote:
> > #9 on Steve Bennett's list is right on target IMHO, but I've had this
> > discussion so many times before, I don't have much energy for it again.
> >
> > """
> > 9. Git history is a bunch of lies
> > The primary output of development work should be source code. Is a
> > well-maintained history really such an important by-product? Most of the
> > arguments for rebase, in particular, rely on aesthetic judgments about
> > “messy merges” in the history, or “unreadable logs”. So rebase encourages
> > you to lie in order to provide other developers with a “clean”,
> > “uncluttered” history. Surely the correct solution is a better log output
> > that can filter out these unwanted merges.
> > """
>
> Well, rebasing aside, my main reason for rewriting history is to ensure that
> each commit is properly separated so that if I ever need something specific
> reverted, I can just git revert and take out that particular change instead
> of having to pick aside the appropriate change from inside the commit.
> git-bisect also works a lot better if your commits are "clean" and
> "uncluttered".
I've tried doing this. Then I looked back and noticed that I was spending a
LOT of time making the VCS pretty, just in case and rarely had to revert
anything. It turned out I was spending a lot of time to save a little time
and that's just not path to being productive.
Scott K
Reply to: