{"thread":{"id":"8571","subject":"Watchpoints","startedAt":"2007-06-12T13:51:16Z","lastAt":"2007-06-12T14:21:50Z","messageCount":2,"participants":["Vegard Nossum","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"44835","messageId":"19f34abd0706120651m2cfab331te0976eddb479b88c@mail.gmail.com","threadId":"8571","inReplyTo":null,"subject":"Watchpoints","fromName":"Vegard Nossum","fromEmail":"vegard.nossum@gmail.com","sentAt":"2007-06-12T13:51:16Z","receivedAt":"2007-06-12T13:51:16Z","isPatch":false,"sender":{"key":"vegard.nossum@gmail.com","avatar":null},"body":"Hello,\n\nA lot of kernel developers consider purely-syntactic changes (ie.\nfixing whitespace issues) to be noisy/disruptive. Therefore, even when\nsuch changes are for the better (according to the coding style, etc),\nthey do not usually make it to the \"mainline\".\n\nIt has been suggested that such syntactic changes be performed and\nsubmitted only when related (nearby) semantic changes are performed at\nthe same time. This is hard to do, however; the developers who want to\nmake semantic changes are not necesarily the same as those who want to\nmake syntactic changes, and thus they may not even realize their\nopportunity to fix, for example, whitespace issues which exist the\nfunction they are changing.\n\nI introduce the concept of watchpoints. In this particular case, a\nwatchpoint is the record of a line (or lines) in a file which has some\nissue that is not serious enough to warrant a change on its own, but\ncould be changed in the future if a nearby change was made. More\ngenerally, a watchpoint can \"watch\" a specific part of a file for\nchanges in the future.\n\nThe point is that git can track a set of watchpoints so that\nwatchpoint line-numbers stay in sync with the actual file contents.\nAdding a line to the beginning a file should probably jump up all the\nwatchpoint line-numbers for that file. Now, git may also check\nto-be-applied patches for changes that touch a watched line.\n\nDoes this sound like a viable or even useful idea for a file tracker?\n\nKind regards,\nVegard Nossum\n"},{"id":"44838","messageId":"Pine.LNX.4.64.0706121514280.4059@racer.site","threadId":"8571","inReplyTo":"19f34abd0706120651m2cfab331te0976eddb479b88c@mail.gmail.com","subject":"Re: Watchpoints","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-12T14:21:50Z","receivedAt":"2007-06-12T14:21:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 12 Jun 2007, Vegard Nossum wrote:\n\n> A lot of kernel developers consider purely-syntactic changes (ie. fixing \n> whitespace issues) to be noisy/disruptive. Therefore, even when such \n> changes are for the better (according to the coding style, etc), they do \n> not usually make it to the \"mainline\".\n\nFWIW I don't think that there are that many developers who think \nwhitespace fixes are useless. For example, Git recently saw a small series \nwhich did nothing _except_ white space fixes.\n\nAnd I can see the value of it. Just take your home as an example. You are \nused to a certain order of things there. I, for one, have a routine where \nI go when coming home, and where I expect my wine bottle to be. If that \nbottle is somewhere else, I have to find it first. It's just a tiny itch, \nbut a real one.\n\nThe same applies to source code: when I am hacking on Git, I expect things \nin a certain layout, and find my way easily through that. If there are \nsome things I am not used to (yes, even a missing space after an \"if\"), it \ntakes away my attention briefly from what I want to do. It's just a tiny \nitch, but a real one.\n\nIf tiny itches add up, they become larger ones. And soon you have a real \nproblem.\n\nSo, if somebody tells you that code style does not matter, ignore her. She \nhas no clue about how people tick, really.\n\nCiao,\nDscho\n"}]}