From: "Vegard Nossum" <vegard.nossum@gmail.com>
To: git@vger.kernel.org
Subject: Watchpoints
Date: Tue, 12 Jun 2007 15:51:16 +0200 [thread overview]
Message-ID: <19f34abd0706120651m2cfab331te0976eddb479b88c@mail.gmail.com> (raw)
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
next reply other threads:[~2007-06-12 13:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-12 13:51 Vegard Nossum [this message]
2007-06-12 14:21 ` Watchpoints Johannes Schindelin
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=19f34abd0706120651m2cfab331te0976eddb479b88c@mail.gmail.com \
--to=vegard.nossum@gmail.com \
--cc=git@vger.kernel.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox