From: Robert Thorpe <rt@robertthorpeconsulting.com>
To: Emanuel Berg <embe8573@student.uu.se>
Cc: help-gnu-emacs@gnu.org
Subject: Re: removing white space highlight
Date: Sun, 28 Feb 2016 18:09:52 +0000 [thread overview]
Message-ID: <87povgvh8v.fsf@robertthorpeconsulting.com> (raw)
In-Reply-To: <877fhph7vu.fsf@debian.uxu> (message from Emanuel Berg on Sun, 28 Feb 2016 03:43:33 +0100)
Emanuel Berg <embe8573@student.uu.se> writes:
> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>> But, what if Harry just deleted some extraneous
>> whitespace from the end of the line? In that case we
>> can't be sure when important_parameter was last set.
>> It may be very old.
>
> You can do it to the entire project once (and do
> nothing else at that point).
Let's say I remove whitespace from the entire project. I then check the
project back in. Every line that has whitespace removed is flagged as
modified. It's added to the repository with my name, date and a new
revision number. So, the problem I've described still occurs.
To go back to my previous example
$ svn blame nasty.c
103 sally /* important_parameter should be */
103 sally /* set for modern memory sizes. */
110 rob int important_parameter = 42;
103 sally
Here, I have removed all the whitespace at revision 110. That makes it
look as though I set the value of important_parameter then. In fact, it
was set much earlier.
After a long time (maybe a decade), the vast majority of lines in all
the files would have been changed. After that the problem wouldn't
arise again, but it's a very high price to pay.
Of course, if it were possible to modify the version control program
then this would be possible. Doing that is "non-trivial", as they say.
> Then add automatic
> cleaning upon submission, don't log the cleaning, and
> last propagate the correct files to anyone who doesn't
> have them.
>
>> Not all version controls systems have that.
>
> Apparently not :)
You don't understand version control systems. You can't change how they
work easily.
>> It's also not very well known and tools that use the
>> VC system (GUIs and Editors) may not use it.
>
> The editors don't need it, tho it can be useful for
> other purposes (e.g., your own files) and it doesn't
> hurt having it there as well.
This part of the discussion was about what happens if the version
control system has an option to deal with whitespace changes. For
example, "-x -b" in Subversion.
In a large project, are you going to tell people that they can't use
front-ends to version-control?
Let's say, for example, that Vim doesn't support those switches. Are you
going to say "I'm sorry Vim users, you have to use command line svn."
BR,
Robert Thorpe
next prev parent reply other threads:[~2016-02-28 18:09 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-18 10:06 removing white space highlight Luca Ferrari
2016-02-18 10:19 ` Gian Uberto Lauri
2016-02-18 10:54 ` Luca Ferrari
2016-02-18 10:30 ` tomas
2016-02-18 13:34 ` Luca Ferrari
2016-02-18 13:17 ` tomas
2016-02-18 14:37 ` Luca Ferrari
2016-02-18 14:15 ` tomas
2016-02-18 16:08 ` Luca Ferrari
2016-02-19 0:23 ` Emanuel Berg
2016-02-19 1:05 ` Drew Adams
2016-02-19 16:02 ` Marcin Borkowski
2016-02-19 20:43 ` Emanuel Berg
2016-02-19 20:50 ` Marcin Borkowski
2016-02-20 0:30 ` Emanuel Berg
2016-02-20 19:08 ` Bob Proulx
2016-02-21 0:32 ` Emanuel Berg
2016-02-21 1:34 ` Bob Proulx
2016-02-21 1:48 ` Emanuel Berg
2016-02-21 3:27 ` Robert Thorpe
2016-02-21 3:31 ` Emanuel Berg
2016-02-21 5:00 ` Marcin Borkowski
2016-02-21 6:10 ` Emanuel Berg
2016-02-21 11:48 ` tomas
2016-02-21 17:13 ` Emanuel Berg
2016-02-23 0:33 ` Robert Thorpe
2016-02-23 0:41 ` Emanuel Berg
2016-02-24 0:44 ` Robert Thorpe
2016-02-24 1:41 ` Emanuel Berg
2016-02-24 20:38 ` Robert Thorpe
2016-02-25 0:10 ` Emanuel Berg
2016-02-25 8:47 ` Luca Ferrari
2016-02-25 9:29 ` Christian Kruse
2016-02-25 19:58 ` Robert Thorpe
2016-02-25 20:10 ` vc-region-history promotion (was: removing white space highlight) Stefan Monnier
2016-02-25 22:15 ` removing white space highlight Emanuel Berg
2016-02-25 22:41 ` Robert Thorpe
2016-02-26 0:02 ` Emanuel Berg
2016-02-26 2:58 ` Robert Thorpe
2016-02-26 3:29 ` Emanuel Berg
2016-02-26 6:08 ` Bob Proulx
2016-02-26 19:48 ` Emanuel Berg
2016-02-27 20:54 ` Robert Thorpe
2016-02-28 2:43 ` Emanuel Berg
2016-02-28 18:09 ` Robert Thorpe [this message]
2016-02-29 0:52 ` Emanuel Berg
2016-02-29 2:43 ` Robert Thorpe
2016-02-22 14:05 ` Luca Ferrari
2016-02-23 0:13 ` Emanuel Berg
2016-02-23 0:34 ` Robert Thorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87povgvh8v.fsf@robertthorpeconsulting.com \
--to=rt@robertthorpeconsulting.com \
--cc=embe8573@student.uu.se \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.