+1 for a gradual perl tidy too
Even then, still don't like the idea of blocking a patch for tabs and spaces ..
The more history we pile on top of that, the longer it'll take git to update the index, and then restore back to master when you're done. If you're tracing out lots of blames, then this can be a serious crimp in workflow.
-Ian
* Ian Walls (koha.sekjal@gmail.com) wrote:
> Doing a large updating commit does not cost us any history.A It just
> counts as an "update" to the code, even though none of the logic has> changed.A A This change would alter SLOC counts and such, messing with
> our statistics, since we only want to measure intellectually significant> contributions (tidying someone else's work doesn't make it yours).A There
> is no way for Git to know if a change to a line of text is a logical> doesn't understand Perl.A There isn't too much we can do about this.
> change or just a formatting change (aside from whitespace), because Git
It's not so much statistics I care about, although I do. But also that
it makes it hard to to do a git blame to find which commit actually
changed the line. Since now every line is changed by the same commit.
Chris
>
> So, best to keep cleaning up incrementally, I think.A As we move from C4
> to Koha, that'll be an opportunity to clean up all the modules> -----UrsprA 1/4ngliche Nachricht-----
>
> -Ian
>
> 2012/3/8 Jared Camins-Esakov <jcamins@cpbibliography.com>
>
> +1 to a gradual perltidy
>
> 2012/3/8 Fischer, Katrin <Katrin.Fischer@bsz-bw.de>
>
> I agree with Chris C. and Chris N. - I think what we would win does
> not outweigh the loss of history.
>
> Katrin
>
Chris Cormack> Von: koha-devel-bounces@lists.koha-community.org im Auftrag von Chris
> Nighswonger
> Gesendet: Do 08.03.2012 19:26
> An: Chris Cormack
> Cc: koha-devel@lists.koha-community.org
> Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process
>
> 2012/3/8 Chris Cormack <chris@bigballofwax.co.nz>
>
> > My counter proposal is tidy as you go. Fix code as you touch it.
> >
> > With vim (and other editors) you can easily tidy a block, doing that
> as
> > code is changed would be my preference.
> >
>
> I'd prefer a "pay-as-you-go" approach as well. We could simply require
> all
> work to be tidied before submitting.
>
> Slow? Yes, but not nearly as messy and preserves the history.
>
> Kind Regards,
> Chris
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
> --
> Jared Camins-Esakov
> Bibliographer, C & P Bibliography Services, LLC
> (phone) +1 (917) 727-3445
> (e-mail) jcamins@cpbibliography.com
> (web) http://www.cpbibliography.com/
> _______________________________________________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> _______________________________________________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
--
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand