r18707 - gnucash/trunk/src/gnome-utils - Change file loading message to "Loading user data..."

[Geert Janssens]

On Tuesday 23 February 2010, Christian Stimming wrote:
> Am Montag, 22. Februar 2010 schrieb Geert Janssens:
> > Author: gjanssens
> > Date: 2010-02-22 10:47:33 -0500 (Mon, 22 Feb 2010)
> > New Revision: 18707
> > Trac: http://svn.gnucash.org/trac/changeset/18707
> >
> > Modified:
> >    gnucash/trunk/src/gnome-utils/gnc-file.c
> > Log:
> > Change file loading message to "Loading user data..."
> >
> > Reading file is technically only correct for files not for databases.
> 
> This patch changed plenty of of lines within that file. Was there a
>  specific reason to do this in the same commit as the actual change? It's
>  not so nice to read through lines and lines of whitespace changes, or
>  comment spelling fixes, to finally find the actual changed code lines.
> 
> I would have strongly preferred to have one commit for the actual message
> change, and another one for all the other cosmetic changes. Git-gui makes
>  this extremely easy by its "Stage context" function; I don't know whether
>  other VC systems are helpful for this sort of operation, though.
> 
> At least, I would kindly ask that your commit message should mention
>  something like "Additionally, some spelling fixes in comments and plenty
>  of whitespace cleanup."
> 
> Just to clarify again: I'm not at all against cosmetic changes or
>  whitespace cleanup - they are very helpful and we can have plenty of
>  those. But I would like to have them in clearly marked commits, very
>  separate from the actual functional changes.
> 
> Thanks!
> 
> Regards,
> 
> Christian
I normally pay attention to making clean commits, but apparently this one 
slipped through. Sorry about that.

I work from within Eclipse and use its built-in svn integration for commits. 
Eclipse automatically removes trailing white space from any file you edit. 
It's an option that can be enabled/disabled, but I had it enabled because I 
tend to add whitespace myself otherwise and knowing you are working to cleanup 
the code base with astyle, I didn't want to create new trailing whitespace. 
But the knife cuts both ways, it also removes any trailing whitespace that's 
still available.

Combine that with subversion that doesn't have something like git's staging 
concept, and you get to my sloppy commit.

I'll pay more attention in the future and split the changes into functional 
subcommits (one for real code change, another for cosmetics).

Geert