* Watchpoints
@ 2007-06-12 13:51 Vegard Nossum
2007-06-12 14:21 ` Watchpoints Johannes Schindelin
0 siblings, 1 reply; 2+ messages in thread
From: Vegard Nossum @ 2007-06-12 13:51 UTC (permalink / raw)
To: git
Hello,
A lot of kernel developers consider purely-syntactic changes (ie.
fixing whitespace issues) to be noisy/disruptive. Therefore, even when
such changes are for the better (according to the coding style, etc),
they do not usually make it to the "mainline".
It has been suggested that such syntactic changes be performed and
submitted only when related (nearby) semantic changes are performed at
the same time. This is hard to do, however; the developers who want to
make semantic changes are not necesarily the same as those who want to
make syntactic changes, and thus they may not even realize their
opportunity to fix, for example, whitespace issues which exist the
function they are changing.
I introduce the concept of watchpoints. In this particular case, a
watchpoint is the record of a line (or lines) in a file which has some
issue that is not serious enough to warrant a change on its own, but
could be changed in the future if a nearby change was made. More
generally, a watchpoint can "watch" a specific part of a file for
changes in the future.
The point is that git can track a set of watchpoints so that
watchpoint line-numbers stay in sync with the actual file contents.
Adding a line to the beginning a file should probably jump up all the
watchpoint line-numbers for that file. Now, git may also check
to-be-applied patches for changes that touch a watched line.
Does this sound like a viable or even useful idea for a file tracker?
Kind regards,
Vegard Nossum
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Watchpoints
2007-06-12 13:51 Watchpoints Vegard Nossum
@ 2007-06-12 14:21 ` Johannes Schindelin
0 siblings, 0 replies; 2+ messages in thread
From: Johannes Schindelin @ 2007-06-12 14:21 UTC (permalink / raw)
To: Vegard Nossum; +Cc: git
Hi,
On Tue, 12 Jun 2007, Vegard Nossum wrote:
> A lot of kernel developers consider purely-syntactic changes (ie. fixing
> whitespace issues) to be noisy/disruptive. Therefore, even when such
> changes are for the better (according to the coding style, etc), they do
> not usually make it to the "mainline".
FWIW I don't think that there are that many developers who think
whitespace fixes are useless. For example, Git recently saw a small series
which did nothing _except_ white space fixes.
And I can see the value of it. Just take your home as an example. You are
used to a certain order of things there. I, for one, have a routine where
I go when coming home, and where I expect my wine bottle to be. If that
bottle is somewhere else, I have to find it first. It's just a tiny itch,
but a real one.
The same applies to source code: when I am hacking on Git, I expect things
in a certain layout, and find my way easily through that. If there are
some things I am not used to (yes, even a missing space after an "if"), it
takes away my attention briefly from what I want to do. It's just a tiny
itch, but a real one.
If tiny itches add up, they become larger ones. And soon you have a real
problem.
So, if somebody tells you that code style does not matter, ignore her. She
has no clue about how people tick, really.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-06-12 14:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-12 13:51 Watchpoints Vegard Nossum
2007-06-12 14:21 ` Watchpoints Johannes Schindelin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox