[parted-devel] nuke trailing blanks *without* inducing conflicts

[Joel Granados]

On Tue, Feb 24, 2009 at 02:22:21PM +0100, Jim Meyering wrote:
> FYI, the condition of Parted's sources has been a thorn
> in our side for too long, and I've just realized that at
> least part of that can be resolved easily: by removing all
> trailing blanks (let's call them TB, like the disease).
> 
> Of course, when you say "global changes", everyone with a grain of
> version-control experience says "don't do that, it'll induce needless
> conflicts".  And they're right -- at first glance.  However, if you
> have an existing change, patch, branch etc. against the old TB-afflicted
> sources, you can easily adjust it to apply to the new, TB-cleaned
> sources.  Just filter it through this:
> 
>   perl -pe 's/[ \t]+$//'
> 
> then it will apply just as well to the post-cleanup as the
> original applied to the pre-cleanup code.
> 
> I've just confirmed that this can be done by demonstrating on
> the 45-change-set "next" branch.
> 
> First I recorded all of the changes on next:
> 
>     git co next
>     git fp --stdout master > next.diff
> 
> Then in my working tree, I made the following change and committed
> the result [note that's a space and a tab in the first pair of brackets]:
> 
>     git grep -l '[ 	]$'|xargs perl -pi -e 's/[ \t]+$//'
> 
> that left me with a (not yet pushed) commit modifying lots of files:
> 
>      107 files changed, 1463 insertions(+), 1463 deletions(-)
> 
> Then I created a branch off that new commit:
> 
>     git co -b next-no-trailing-blanks
> 
> performed the same transformation on the saved patch:
> 
>     perl -pi -e 's/[ \t]+$//' next.diff
> 
> and applied it:
> 
>     git am next.diff
> 
> No conflicts.  and no more trailing blanks.
> Done.
> 
> So, unless someone can come up with a convincing argument
> for *not* making this change, I'll make it soon, rebase "next"
> as outlined above, and enable the "make syntax-check" that will
> spot any violation of the new policy.

Sweet.!!!!

> 
> P.S. Resolving the indent-with-TAB vs indent-with-spaces
> problem may well be nearly as easy.  For another day...

I guess this is not as easy as the TBs because the person who patches
might choose (for whatever reason) to tab with 4 spaces instead of 8.
So doing a "s/        /\t/" is not as trivial.  OTOH, working on the
gpt.c file its kind of difficlut to follow the "pls use whatever
indentation is around" suggestion as at least two types of indentation
can be found in that file (even in the same function).

I grept for all the lines that began with an indentation of 4 spaces.
There are 608 lines with this type of indentation. :(
http://fpaste.org/paste/4377


> 
> Note: things like normalizing indentation levels, brace positioning,
> and general formatting styles are still not even on the radar.
> 
> _______________________________________________
> parted-devel mailing list
> parted-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/parted-devel

-- 
Joel Andres Granados
Brno, Czech Republic, Red Hat.