From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Jonathan H Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Aug 2015 00:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 21383@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.144098196314463 (code B ref -1); Mon, 31 Aug 2015 00:47:01 +0000 Received: (at submit) by debbugs.gnu.org; 31 Aug 2015 00:46:03 +0000 Received: from localhost ([127.0.0.1]:43188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWDEY-0003l9-VN for submit@debbugs.gnu.org; Sun, 30 Aug 2015 20:46:03 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46071) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWDEV-0003kg-Qo for submit@debbugs.gnu.org; Sun, 30 Aug 2015 20:46:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWDEU-0003no-8g for submit@debbugs.gnu.org; Sun, 30 Aug 2015 20:45:59 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:41538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWDEU-0003nk-5m for submit@debbugs.gnu.org; Sun, 30 Aug 2015 20:45:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWDET-0000Nw-2N for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 20:45:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWDER-0003nM-Sf for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 20:45:56 -0400 Received: from mail-ig0-x233.google.com ([2607:f8b0:4001:c05::233]:33060) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWDER-0003nG-Lf for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 20:45:55 -0400 Received: by igbuu8 with SMTP id uu8so37608988igb.0 for ; Sun, 30 Aug 2015 17:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=/MTOfMW//GRkVHh3EK2eNsJfUC0tnhLi7XPbIsslLtI=; b=KLd6NGvvQRA8RmE8fZPlFDMJD4FvlITesU6ApS7uU02V9b6A4uLQ3wS7xJKSDu3+Ia E4Y81Zan88LEe5+KExFG7x9AyeBtBm5PVxPOKrKwa1+Ns2dHPrExLvTPLt48h4Tex/tl MhGiTMJhy2yuJtp4xnpOKZQ+VwMAqiDfkl1iVUyHwN0gHZzMIj0bUn/F4fRHa1xgzydo jbyKDLWMX7y5TXHVQ2DqIvhLoFChHNUWazGNk0Vqol/qk6Ni/msKRYOTpI0fJNVahD35 4KvgbTDgZDOPW3BOtSTJ2pctnOraaVroeHJNYknVHZZfCiwcIAxrUd0r0CPe61rNCXzF 8blQ== X-Received: by 10.50.129.99 with SMTP id nv3mr13400719igb.20.1440981954628; Sun, 30 Aug 2015 17:45:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.110.197 with HTTP; Sun, 30 Aug 2015 17:45:25 -0700 (PDT) From: Jonathan H Date: Sun, 30 Aug 2015 17:45:25 -0700 Message-ID: Content-Type: multipart/mixed; boundary=047d7b3a91e688c54b051e90c151 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --047d7b3a91e688c54b051e90c151 Content-Type: multipart/alternative; boundary=047d7b3a91e688c544051e90c14f --047d7b3a91e688c544051e90c14f Content-Type: text/plain; charset=UTF-8 Hello all! I've attached a basic patch that adds an option to vc-working-revision. The option is named *concrete* and if non-nil, it forces vc-working-revision to return a revision name that will not go stale after new revisions are made. This is useful for, e.g. git, where vc-working-revision will just return the branch name, which only refers to the current commit for as long as it's the head of the branch. I'm using this in diff-hl #33 to determine when to refresh the current VC highlighting. I've supplied an implementation for Git, and no-op implementations for all the other backends. For most systems (i.e. all the other VCS systems I know), the value of *concrete *does not matter. If you know a backend that would benefit from a real implementation, please let me know. Also, this is my first patch, so I'm not entirely sure I've got all my ducks in a row. Any comments on that would be great too. Thanks, Jonathan --047d7b3a91e688c544051e90c14f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all!

I've= attached a basic patch that adds an option to vc-working-revision. The opt= ion is named concrete and if non-nil, it forces vc-working-revision = to return a revision name that will not go stale after new revisions are ma= de.

This is useful for, e.g. git, where vc-working-revisi= on will just return the branch name, which only refers to the current commi= t for as long as it's the head of the branch.

I'm= using this in diff= -hl #33 to determine when to refresh the current VC highlighting.
I've supplied an implementation for Git, and no-op impleme= ntations for all the other backends. For most systems (i.e. all the other V= CS systems I know), the value of concrete does not matter. If you kn= ow a backend that would benefit from a real implementation, please let me k= now.

Also, this is my first patch, so I'm = not entirely sure I've got all my ducks in a row. Any comments on that = would be great too.

Thanks,
Jonathan
--047d7b3a91e688c544051e90c14f-- --047d7b3a91e688c54b051e90c151 Content-Type: application/octet-stream; name="0001-Add-CONCRETE-parameter-to-vc-working-revision.patch" Content-Disposition: attachment; filename="0001-Add-CONCRETE-parameter-to-vc-working-revision.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_idugwl8b0 RnJvbSA1ZmM3ZGZmNzYxMDJlYTFlMDk3YmMzOWNiY2ViOGI3ZDcxZGY0NDdkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQeXRob25OdXQgPFB5dGhvbk51dEB1c2Vycy5ub3JlcGx5Lmdp dGh1Yi5jb20+CkRhdGU6IFNhdCwgMjIgQXVnIDIwMTUgMDE6MjU6NDQgKzAwMDAKU3ViamVjdDog W1BBVENIXSBBZGQgQ09OQ1JFVEUgcGFyYW1ldGVyIHRvIHZjLXdvcmtpbmctcmV2aXNpb24KCklm IENPTkNSRVRFIGlzIG5vbi1uaWwsIHRoZSByZXZpc2lvbiB3aWxsIGJlIHRpZWQgdG8gYW4gdW5h bWJpZ3VvdXMgY29tbWl0Cmluc3RlYWQgb2YgdGhlIG5vcm1hbCBzeW1ib2xpYyByZWYuCi0tLQog bGlzcC92Yy92Yy1ienIuZWwgICB8ICAyICstCiBsaXNwL3ZjL3ZjLWN2cy5lbCAgIHwgIDIgKy0K IGxpc3AvdmMvdmMtZ2l0LmVsICAgfCAxMiArKysrKystLS0tLS0KIGxpc3AvdmMvdmMtaGcuZWwg ICAgfCAgMiArLQogbGlzcC92Yy92Yy1ob29rcy5lbCB8IDE4ICsrKysrKysrKysrLS0tLS0tLQog bGlzcC92Yy92Yy1tdG4uZWwgICB8ICAyICstCiBsaXNwL3ZjL3ZjLXJjcy5lbCAgIHwgIDIgKy0K IGxpc3AvdmMvdmMtc2Njcy5lbCAgfCAgMiArLQogbGlzcC92Yy92Yy1zcmMuZWwgICB8ICAyICst CiBsaXNwL3ZjL3ZjLXN2bi5lbCAgIHwgIDIgKy0KIDEwIGZpbGVzIGNoYW5nZWQsIDI1IGluc2Vy dGlvbnMoKyksIDIxIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpc3AvdmMvdmMtYnpyLmVs IGIvbGlzcC92Yy92Yy1ienIuZWwKaW5kZXggNWY4ZGQwYi4uOTUzMTc5ZSAxMDA2NDQKLS0tIGEv bGlzcC92Yy92Yy1ienIuZWwKKysrIGIvbGlzcC92Yy92Yy1ienIuZWwKQEAgLTUzMiw3ICs1MzIs NyBAQCBSZXR1cm5zIG5pbCBpZiB1bmFibGUgdG8gZmluZCB0aGlzIGluZm9ybWF0aW9uLiIKICAg ICAgICAgICAgICAobG9va2luZy1hdCAiWzAtOV0rXDBcXChbXlwwXG5dK1xcKVwwIikKICAgICAg ICAgICAgICAobWF0Y2gtc3RyaW5nIDEpKSkpKSkKIAotKGRlZnVuIHZjLWJ6ci13b3JraW5nLXJl dmlzaW9uIChmaWxlKQorKGRlZnVuIHZjLWJ6ci13b3JraW5nLXJldmlzaW9uIChmaWxlICZvcHRp b25hbCBjb25jcmV0ZSkKICAgKGxldCogKChyb290ZGlyICh2Yy1ienItcm9vdCBmaWxlKSkKICAg ICAgICAgIChicmFuY2gtZm9ybWF0LWZpbGUgKGV4cGFuZC1maWxlLW5hbWUgdmMtYnpyLWFkbWlu LWJyYW5jaC1mb3JtYXQtZmlsZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICByb290ZGlyKSkKZGlmZiAtLWdpdCBhL2xpc3AvdmMvdmMtY3ZzLmVsIGIvbGlz cC92Yy92Yy1jdnMuZWwKaW5kZXggOWE0MTkwNS4uMjkwYjhjYiAxMDA2NDQKLS0tIGEvbGlzcC92 Yy92Yy1jdnMuZWwKKysrIGIvbGlzcC92Yy92Yy1jdnMuZWwKQEAgLTI1OCw3ICsyNTgsNyBAQCBT ZWUgYWxzbyB2YXJpYWJsZSBgdmMtY3ZzLXN0aWNreS1kYXRlLWZvcm1hdC1zdHJpbmcnLiIKICAg ICAgKChudWxsIGNoZWNrb3V0LXRpbWUpICd1bnJlZ2lzdGVyZWQpCiAgICAgICh0ICdlZGl0ZWQp KSkpCiAKLShkZWZ1biB2Yy1jdnMtd29ya2luZy1yZXZpc2lvbiAoZmlsZSkKKyhkZWZ1biB2Yy1j dnMtd29ya2luZy1yZXZpc2lvbiAoZmlsZSAmb3B0aW9uYWwgY29uY3JldGUpCiAgICJDVlMtc3Bl Y2lmaWMgdmVyc2lvbiBvZiBgdmMtd29ya2luZy1yZXZpc2lvbicuIgogICA7OyBUaGVyZSBpcyBu byBuZWVkIHRvIGNvbnN1bHQgUkNTIGhlYWRlcnMgdW5kZXIgQ1ZTLCBiZWNhdXNlIHdlCiAgIDs7 IGdldCB0aGUgd29ya2ZpbGUgdmVyc2lvbiBmb3IgZnJlZSB3aGVuIHdlIHJlY29nbml6ZSB0aGF0 IGEgZmlsZQpkaWZmIC0tZ2l0IGEvbGlzcC92Yy92Yy1naXQuZWwgYi9saXNwL3ZjL3ZjLWdpdC5l bAppbmRleCA5NTIyMzI4Li44NGUyMDI1IDEwMDY0NAotLS0gYS9saXNwL3ZjL3ZjLWdpdC5lbAor KysgYi9saXNwL3ZjL3ZjLWdpdC5lbApAQCAtMjQ4LDE1ICsyNDgsMTUgQEAgbWF0Y2hpbmcgdGhl IHJlc3VsdGluZyBHaXQgbG9nIG91dHB1dCwgYW5kIEtFWVdPUkRTIGlzIGEgbGlzdCBvZgogICAg ICAgICAgICAgKHZjLWdpdC0tc3RhdGUtY29kZSBkaWZmLWxldHRlcikpKQogICAgICAgKGlmICh2 Yy1naXQtLWVtcHR5LWRiLXApICdhZGRlZCAndXAtdG8tZGF0ZSkpKSkKIAotKGRlZnVuIHZjLWdp dC13b3JraW5nLXJldmlzaW9uIChmaWxlKQorKGRlZnVuIHZjLWdpdC13b3JraW5nLXJldmlzaW9u IChmaWxlICZvcHRpb25hbCBjb25jcmV0ZSkKICAgIkdpdC1zcGVjaWZpYyB2ZXJzaW9uIG9mIGB2 Yy13b3JraW5nLXJldmlzaW9uJy4iCiAgIChsZXQqIChwcm9jZXNzLWZpbGUtc2lkZS1lZmZlY3Rz Ci0gICAgICAgICAoc3RyICh2Yy1naXQtLXJ1bi1jb21tYW5kLXN0cmluZyBuaWwgInN5bWJvbGlj LXJlZiIgIkhFQUQiKSkpCisgICAgICAgICAgKHN0ciAodmMtZ2l0LS1ydW4tY29tbWFuZC1zdHJp bmcgbmlsICJzeW1ib2xpYy1yZWYiICJIRUFEIikpKQogICAgICh2Yy1maWxlLXNldHByb3AgZmls ZSAndmMtZ2l0LWRldGFjaGVkIChudWxsIHN0cikpCi0gICAgKGlmIHN0cgotICAgICAgICAoaWYg KHN0cmluZy1tYXRjaCAiXlxcKHJlZnMvaGVhZHMvXFwpP1xcKC4rXFwpJCIgc3RyKQotICAgICAg ICAgICAgKG1hdGNoLXN0cmluZyAyIHN0cikKLSAgICAgICAgICBzdHIpCisgICAgKGlmIChhbmQg c3RyIChub3QgY29uY3JldGUpKQorICAgICAgKGlmIChzdHJpbmctbWF0Y2ggIl5cXChyZWZzL2hl YWRzL1xcKT9cXCguK1xcKSQiIHN0cikKKyAgICAgICAgKG1hdGNoLXN0cmluZyAyIHN0cikKKyAg ICAgICAgc3RyKQogICAgICAgKHZjLWdpdC0tcmV2LXBhcnNlICJIRUFEIikpKSkKIAogKGRlZnVu IHZjLWdpdC1tb2RlLWxpbmUtc3RyaW5nIChmaWxlKQpkaWZmIC0tZ2l0IGEvbGlzcC92Yy92Yy1o Zy5lbCBiL2xpc3AvdmMvdmMtaGcuZWwKaW5kZXggZjYzNGUyZS4uZWVlOGM4NSAxMDA2NDQKLS0t IGEvbGlzcC92Yy92Yy1oZy5lbAorKysgYi9saXNwL3ZjL3ZjLWhnLmVsCkBAIC0yMzcsNyArMjM3 LDcgQEAgaGlnaGxpZ2h0aW5nIHRoZSBMb2cgVmlldyBidWZmZXIuIgogCSAoKGVxIHN0YXRlID9D KSAndXAtdG8tZGF0ZSkgOzsgT2xkZXIgbWVyY3VyaWFsIHZlcnNpb25zIHVzZSB0aGlzLgogCSAo dCAndXAtdG8tZGF0ZSkpKSkpKQogCi0oZGVmdW4gdmMtaGctd29ya2luZy1yZXZpc2lvbiAoZmls ZSkKKyhkZWZ1biB2Yy1oZy13b3JraW5nLXJldmlzaW9uIChmaWxlICZvcHRpb25hbCBjb25jcmV0 ZSkKICAgIkhnLXNwZWNpZmljIHZlcnNpb24gb2YgYHZjLXdvcmtpbmctcmV2aXNpb24nLiIKICAg KG9yIChpZ25vcmUtZXJyb3JzCiAgICAgICAgICh3aXRoLW91dHB1dC10by1zdHJpbmcKZGlmZiAt LWdpdCBhL2xpc3AvdmMvdmMtaG9va3MuZWwgYi9saXNwL3ZjL3ZjLWhvb2tzLmVsCmluZGV4IGJh ZTk5MTkuLjUwNGVmYjkgMTAwNjQ0Ci0tLSBhL2xpc3AvdmMvdmMtaG9va3MuZWwKKysrIGIvbGlz cC92Yy92Yy1ob29rcy5lbApAQCAtNDkwLDE1ICs0OTAsMTkgQEAgc3RhdHVzIG9mIHRoaXMgZmls ZS4gIE90aGVyd2lzZSwgdGhlIHZhbHVlIHJldHVybmVkIGlzIG9uZSBvZjoKICAgIkNvbnZlbmll bmNlIGZ1bmN0aW9uIHRoYXQgY2hlY2tzIHdoZXRoZXIgYHZjLXN0YXRlJyBvZiBGSUxFIGlzIGB1 cC10by1kYXRlJy4iCiAgIChlcSAodmMtc3RhdGUgZmlsZSkgJ3VwLXRvLWRhdGUpKQogCi0oZGVm dW4gdmMtd29ya2luZy1yZXZpc2lvbiAoZmlsZSAmb3B0aW9uYWwgYmFja2VuZCkKKyhkZWZ1biB2 Yy13b3JraW5nLXJldmlzaW9uIChmaWxlICZvcHRpb25hbCBiYWNrZW5kIGNvbmNyZXRlKQogICAi UmV0dXJuIHRoZSByZXBvc2l0b3J5IHZlcnNpb24gZnJvbSB3aGljaCBGSUxFIHdhcyBjaGVja2Vk IG91dC4KLUlmIEZJTEUgaXMgbm90IHJlZ2lzdGVyZWQsIHRoaXMgZnVuY3Rpb24gYWx3YXlzIHJl dHVybnMgbmlsLiIKLSAgKG9yICh2Yy1maWxlLWdldHByb3AgZmlsZSAndmMtd29ya2luZy1yZXZp c2lvbikKK0lmIEZJTEUgaXMgbm90IHJlZ2lzdGVyZWQsIHRoaXMgZnVuY3Rpb24gYWx3YXlzIHJl dHVybnMgbmlsLgorSWYgQ09OQ1JFVEUgaXMgbm9uLW5pbCwgdGhlIHJldmlzaW9uIHdpbGwgYmUg dGllZCB0byBhbiB1bmFtYmlndW91cyBjb21taXQKK2luc3RlYWQgb2YgdGhlIG5vcm1hbCBzeW1i b2xpYyByZWYuIgorICAoaWYgY29uY3JldGUKKyAgICAodmMtY2FsbC1iYWNrZW5kIGJhY2tlbmQg J3dvcmtpbmctcmV2aXNpb24gZmlsZSB0KQorICAgIChvciAodmMtZmlsZS1nZXRwcm9wIGZpbGUg J3ZjLXdvcmtpbmctcmV2aXNpb24pCiAgICAgICAocHJvZ24KLQkoc2V0cSBiYWNrZW5kIChvciBi YWNrZW5kICh2Yy1yZXNwb25zaWJsZS1iYWNrZW5kIGZpbGUpKSkKLQkod2hlbiBiYWNrZW5kCi0J ICAodmMtZmlsZS1zZXRwcm9wIGZpbGUgJ3ZjLXdvcmtpbmctcmV2aXNpb24KLQkJCSAgICh2Yy1j YWxsLWJhY2tlbmQgYmFja2VuZCAnd29ya2luZy1yZXZpc2lvbiBmaWxlKSkpKSkpCisgICAgICAg IChzZXRxIGJhY2tlbmQgKG9yIGJhY2tlbmQgKHZjLXJlc3BvbnNpYmxlLWJhY2tlbmQgZmlsZSkp KQorICAgICAgICAod2hlbiBiYWNrZW5kCisgICAgICAgICAgKHZjLWZpbGUtc2V0cHJvcCBmaWxl ICd2Yy13b3JraW5nLXJldmlzaW9uCisgICAgICAgICAgICAodmMtY2FsbC1iYWNrZW5kIGJhY2tl bmQgJ3dvcmtpbmctcmV2aXNpb24gZmlsZSkpKSkpKSkKIAogOzsgQmFja3dhcmQgY29tcGF0aWJp bGl0eS4KIChkZWZpbmUtb2Jzb2xldGUtZnVuY3Rpb24tYWxpYXMKZGlmZiAtLWdpdCBhL2xpc3Av dmMvdmMtbXRuLmVsIGIvbGlzcC92Yy92Yy1tdG4uZWwKaW5kZXggNjg1ZWYzYi4uNjNlZmI5ZiAx MDA2NDQKLS0tIGEvbGlzcC92Yy92Yy1tdG4uZWwKKysrIGIvbGlzcC92Yy92Yy1tdG4uZWwKQEAg LTE0Nyw3ICsxNDcsNyBAQCBzd2l0Y2hlcy4iCiAgICh2Yy1ydW4tZGVsYXllZAogICAgKHZjLW10 bi1hZnRlci1kaXItc3RhdHVzIHVwZGF0ZS1mdW5jdGlvbikpKQogCi0oZGVmdW4gdmMtbXRuLXdv cmtpbmctcmV2aXNpb24gKGZpbGUpCisoZGVmdW4gdmMtbXRuLXdvcmtpbmctcmV2aXNpb24gKGZp bGUgJm9wdGlvbmFsIGNvbmNyZXRlKQogICA7OyBJZiBgbXRuJyBmYWlscyBvciByZXR1cm5zIHN0 YXR1cz4wLCBvciBpZiB0aGUgc2VhcmNoIGZhaWxzLCBqdXN0CiAgIDs7IHJldHVybiBuaWwuCiAg IChpZ25vcmUtZXJyb3JzCmRpZmYgLS1naXQgYS9saXNwL3ZjL3ZjLXJjcy5lbCBiL2xpc3AvdmMv dmMtcmNzLmVsCmluZGV4IDcxZmZhNTUuLjVhNWVkNzYgMTAwNjQ0Ci0tLSBhL2xpc3AvdmMvdmMt cmNzLmVsCisrKyBiL2xpc3AvdmMvdmMtcmNzLmVsCkBAIC0xNjgsNyArMTY4LDcgQEAgRm9yIGEg ZGVzY3JpcHRpb24gb2YgcG9zc2libGUgdmFsdWVzLCBzZWUgYHZjLWNoZWNrLW1hc3Rlci10ZW1w bGF0ZXMnLiIKIAkgIChwdXNoIChsaXN0IGZyZWwgc3RhdGUpIHJlc3VsdCkpKSkKICAgICAoZnVu Y2FsbCB1cGRhdGUtZnVuY3Rpb24gcmVzdWx0KSkpCiAKLShkZWZ1biB2Yy1yY3Mtd29ya2luZy1y ZXZpc2lvbiAoZmlsZSkKKyhkZWZ1biB2Yy1yY3Mtd29ya2luZy1yZXZpc2lvbiAoZmlsZSAmb3B0 aW9uYWwgY29uY3JldGUpCiAgICJSQ1Mtc3BlY2lmaWMgdmVyc2lvbiBvZiBgdmMtd29ya2luZy1y ZXZpc2lvbicuIgogICAob3IgKGFuZCB2Yy1jb25zdWx0LWhlYWRlcnMKICAgICAgICAgICAgKHZj LXJjcy1jb25zdWx0LWhlYWRlcnMgZmlsZSkKZGlmZiAtLWdpdCBhL2xpc3AvdmMvdmMtc2Njcy5l bCBiL2xpc3AvdmMvdmMtc2Njcy5lbAppbmRleCA4ZDhkOWU4Li5mN2ZkYjczIDEwMDY0NAotLS0g YS9saXNwL3ZjL3ZjLXNjY3MuZWwKKysrIGIvbGlzcC92Yy92Yy1zY2NzLmVsCkBAIC0xNDcsNyAr MTQ3LDcgQEAgRm9yIGEgZGVzY3JpcHRpb24gb2YgcG9zc2libGUgdmFsdWVzLCBzZWUgYHZjLWNo ZWNrLW1hc3Rlci10ZW1wbGF0ZXMnLiIKIAogKGF1dG9sb2FkICd2Yy1tYXN0ZXItbmFtZSAidmMt ZmlsZXdpc2UiKQogCi0oZGVmdW4gdmMtc2Njcy13b3JraW5nLXJldmlzaW9uIChmaWxlKQorKGRl ZnVuIHZjLXNjY3Mtd29ya2luZy1yZXZpc2lvbiAoZmlsZSAmb3B0aW9uYWwgY29uY3JldGUpCiAg ICJTQ0NTLXNwZWNpZmljIHZlcnNpb24gb2YgYHZjLXdvcmtpbmctcmV2aXNpb24nLiIKICAgKHdo ZW4gKGFuZCAoZmlsZS1yZWd1bGFyLXAgZmlsZSkgKHZjLW1hc3Rlci1uYW1lIGZpbGUpKQogICAg ICh3aXRoLXRlbXAtYnVmZmVyCmRpZmYgLS1naXQgYS9saXNwL3ZjL3ZjLXNyYy5lbCBiL2xpc3Av dmMvdmMtc3JjLmVsCmluZGV4IGQ5YWExYjEuLmQyZGQ1MDUgMTAwNjQ0Ci0tLSBhL2xpc3AvdmMv dmMtc3JjLmVsCisrKyBiL2xpc3AvdmMvdmMtc3JjLmVsCkBAIC0xOTgsNyArMTk4LDcgQEAgVGhp cyBmdW5jdGlvbiBkaWZmZXJzIGZyb20gdmMtZG8tY29tbWFuZCBpbiB0aGF0IGl0IGludm9rZXMg YHZjLXNyYy1wcm9ncmFtJy4iCiAJICAgKHNldHEgZmlsZS1saXN0IChjb25zICItLSIgZmlsZS1v ci1saXN0KSkpKQogICAgIChhcHBseSAndmMtZG8tY29tbWFuZCAob3IgYnVmZmVyICIqdmMqIikg MCB2Yy1zcmMtcHJvZ3JhbSBmaWxlLWxpc3QgZmxhZ3MpKSkKIAotKGRlZnVuIHZjLXNyYy13b3Jr aW5nLXJldmlzaW9uIChmaWxlKQorKGRlZnVuIHZjLXNyYy13b3JraW5nLXJldmlzaW9uIChmaWxl ICZvcHRpb25hbCBjb25jcmV0ZSkKICAgIlNSQy1zcGVjaWZpYyB2ZXJzaW9uIG9mIGB2Yy13b3Jr aW5nLXJldmlzaW9uJy4iCiAgIChsZXQgKChyZXN1bHQgKGlnbm9yZS1lcnJvcnMKIAkJICAod2l0 aC1vdXRwdXQtdG8tc3RyaW5nCmRpZmYgLS1naXQgYS9saXNwL3ZjL3ZjLXN2bi5lbCBiL2xpc3Av dmMvdmMtc3ZuLmVsCmluZGV4IDhkNmVhZTUuLjAxY2IxZTQgMTAwNjQ0Ci0tLSBhL2xpc3AvdmMv dmMtc3ZuLmVsCisrKyBiL2xpc3AvdmMvdmMtc3ZuLmVsCkBAIC0yNDAsNyArMjQwLDcgQEAgUkVT VUxUIGlzIGEgbGlzdCBvZiBjb25zZXMgKEZJTEUgLiBTVEFURSkgZm9yIGRpcmVjdG9yeSBESVIu IgogCSAgICAgKHByb3BlcnRpemUgcmVwbyAnZmFjZSAnZm9udC1sb2NrLXZhcmlhYmxlLW5hbWUt ZmFjZSkpKQogCSAgICh0ICIiKSkpKSkKIAotKGRlZnVuIHZjLXN2bi13b3JraW5nLXJldmlzaW9u IChmaWxlKQorKGRlZnVuIHZjLXN2bi13b3JraW5nLXJldmlzaW9uIChmaWxlICZvcHRpb25hbCBj b25jcmV0ZSkKICAgIlNWTi1zcGVjaWZpYyB2ZXJzaW9uIG9mIGB2Yy13b3JraW5nLXJldmlzaW9u Jy4iCiAgIDs7IFRoZXJlIGlzIG5vIG5lZWQgdG8gY29uc3VsdCBSQ1MgaGVhZGVycyB1bmRlciBT Vk4sIGJlY2F1c2Ugd2UKICAgOzsgZ2V0IHRoZSB3b3JrZmlsZSB2ZXJzaW9uIGZvciBmcmVlIHdo ZW4gd2UgcmVjb2duaXplIHRoYXQgYSBmaWxlCi0tIAoyLjUuMAoK --047d7b3a91e688c54b051e90c151-- From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Aug 2015 04:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jonathan H Cc: 21383@debbugs.gnu.org Received: via spool by 21383-submit@debbugs.gnu.org id=B21383.14409963195814 (code B ref 21383); Mon, 31 Aug 2015 04:46:02 +0000 Received: (at 21383) by debbugs.gnu.org; 31 Aug 2015 04:45:19 +0000 Received: from localhost ([127.0.0.1]:43314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWGy7-0001Vh-0O for submit@debbugs.gnu.org; Mon, 31 Aug 2015 00:45:19 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:39523) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWGy4-0001VY-IV for 21383@debbugs.gnu.org; Mon, 31 Aug 2015 00:45:17 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AsEwA731xV//rn92hcgxCEAoVVuzcJh0sEAgKBPDkUAQEBAQEBAYEKQQWDXQEBAwFWIwULCzQSFBgNJIg3CM8jAQEBAQYBAQEBHos6hQUHhC0Fi0SpQCOEFCKCeAEBAQ X-IPAS-Result: A0AsEwA731xV//rn92hcgxCEAoVVuzcJh0sEAgKBPDkUAQEBAQEBAYEKQQWDXQEBAwFWIwULCzQSFBgNJIg3CM8jAQEBAQYBAQEBHos6hQUHhC0Fi0SpQCOEFCKCeAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="161906063" Received: from 104-247-231-250.cpe.teksavvy.com (HELO ceviche.home) ([104.247.231.250]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2015 00:45:15 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 3A706661B5; Mon, 31 Aug 2015 00:45:15 -0400 (EDT) From: Stefan Monnier Message-ID: References: Date: Mon, 31 Aug 2015 00:45:15 -0400 In-Reply-To: (Jonathan H.'s message of "Sun, 30 Aug 2015 17:45:25 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > I've supplied an implementation for Git, and no-op implementations for all > the other backends. Actually, I think what you're getting at, is that the current vc-git backend has a bug: the working-revision should not just be the branch name, but should be the actual commit id. Stefan From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Aug 2015 08:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Jonathan H Cc: 21383@debbugs.gnu.org Received: via spool by 21383-submit@debbugs.gnu.org id=B21383.144101086430145 (code B ref 21383); Mon, 31 Aug 2015 08:48:02 +0000 Received: (at 21383) by debbugs.gnu.org; 31 Aug 2015 08:47:44 +0000 Received: from localhost ([127.0.0.1]:43426 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWKki-0007q9-Ds for submit@debbugs.gnu.org; Mon, 31 Aug 2015 04:47:44 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:36111) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWKkf-0007pz-No for 21383@debbugs.gnu.org; Mon, 31 Aug 2015 04:47:42 -0400 Received: by wicfv10 with SMTP id fv10so56266403wic.1 for <21383@debbugs.gnu.org>; Mon, 31 Aug 2015 01:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=JyY3I2xsQGyBZlv75u5+burL26vVFpoABsngnvHEP9o=; b=pHT6am7lzH5UG9ljF1ftQ1XbKCvpVshjQAWrBFZwQ6b9+C4U3e1I0XiiBtSZWUoHdp llFg6/cNvRBRgmDob63FkYJSLbhmcYiQYkfTxcTAfa/pzoT1sox6JE2NKODPdc5oc/Dt wbYlAH1+QTu91JBLsRrKkBmZgmRZtKjntwlrvhLRfLBFoHFCmzZ7bdzTnOmb5ipWIKUa +RZZtDjEoQ57mFylOwA9Cfq0dWlc3MpYRgGGa8kcltzvVojzn6i87F0B4aSJv4CN9H15 ooR6WJYKcRbOzfR51qFW0xFHYtkIMoA6DaVpMPyA2+uoklvONL+A/m3stiEjkNPSEr+C T+PA== X-Received: by 10.180.101.164 with SMTP id fh4mr19021994wib.25.1441010860997; Mon, 31 Aug 2015 01:47:40 -0700 (PDT) Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id sd14sm2955261wjb.36.2015.08.31.01.47.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Aug 2015 01:47:40 -0700 (PDT) References: From: Dmitry Gutov Message-ID: <55E41499.5030501@yandex.ru> Date: Mon, 31 Aug 2015 11:47:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 08/31/2015 07:45 AM, Stefan Monnier wrote: > Actually, I think what you're getting at, is that the current vc-git > backend has a bug: the working-revision should not just be the branch > name, but should be the actual commit id. That's one possible conclusion. But if we simply change vc-git-working-revision to always return a concrete revision, vc-git-mode-line-string would return it as well. And being able to see the current branch in the mode-line is pretty handy. From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Aug 2015 17:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383@debbugs.gnu.org, Jonathan H Received: via spool by 21383-submit@debbugs.gnu.org id=B21383.14410430524265 (code B ref 21383); Mon, 31 Aug 2015 17:45:02 +0000 Received: (at 21383) by debbugs.gnu.org; 31 Aug 2015 17:44:12 +0000 Received: from localhost ([127.0.0.1]:43886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWT7s-00016j-Gm for submit@debbugs.gnu.org; Mon, 31 Aug 2015 13:44:12 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:11323) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWT7r-00016c-1B for 21383@debbugs.gnu.org; Mon, 31 Aug 2015 13:44:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AsEwA731xV//rn92hcgxCEAoVVuzcJh0sEAgKBPDkUAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBAQEBBQEBAQEeizqFBQeELQWLRKlAI4QUIoJ4AQEB X-IPAS-Result: A0AsEwA731xV//rn92hcgxCEAoVVuzcJh0sEAgKBPDkUAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBAQEBBQEBAQEeizqFBQeELQWLRKlAI4QUIoJ4AQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="161963107" Received: from 104-247-231-250.cpe.teksavvy.com (HELO pastel.home) ([104.247.231.250]) by ironport2-out.teksavvy.com with ESMTP; 31 Aug 2015 13:44:10 -0400 Received: by pastel.home (Postfix, from userid 20848) id 1BAF662254; Mon, 31 Aug 2015 13:44:10 -0400 (EDT) From: Stefan Monnier Message-ID: References: <55E41499.5030501@yandex.ru> Date: Mon, 31 Aug 2015 13:44:10 -0400 In-Reply-To: <55E41499.5030501@yandex.ru> (Dmitry Gutov's message of "Mon, 31 Aug 2015 11:47:21 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > And being able to see the current branch in the mode-line is pretty handy. So we need to change vc-git-mode-line-string to put the branch name in there. Doesn't seem particularly hard. Stefan From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Sep 2015 02:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 21383@debbugs.gnu.org, Jonathan H Received: via spool by 21383-submit@debbugs.gnu.org id=B21383.14410734895588 (code B ref 21383); Tue, 01 Sep 2015 02:12:01 +0000 Received: (at 21383) by debbugs.gnu.org; 1 Sep 2015 02:11:29 +0000 Received: from localhost ([127.0.0.1]:44512 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWb2m-0001S4-HE for submit@debbugs.gnu.org; Mon, 31 Aug 2015 22:11:28 -0400 Received: from mail-lb0-f170.google.com ([209.85.217.170]:33055) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWb2k-0001Rv-3k for 21383@debbugs.gnu.org; Mon, 31 Aug 2015 22:11:26 -0400 Received: by lbbsx3 with SMTP id sx3so70693143lbb.0 for <21383@debbugs.gnu.org>; Mon, 31 Aug 2015 19:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=LXSXYlr9tVaJG7vZrzrf3xBi9DBuTp46TwwAEsLVuIA=; b=kQV+tvKO4e5ycDiEzEjTEmyA8FKX+6wyzZR7xXYXVLgDXUVMcAJdOvPlBOqUEG+UP9 hmZYRVUep48BlPPuG3RggWfzX18kFidEU+nwVOaXA3ZD8v8KVZcNxRIJhxawtNGTnzwS rexR7onXllOFvmWGLJbUt0biN3ieVqUMnoLc3hPVmKNEDyMtq9/e05gXmlqe4tjrdRiD MUKKYvyTPAaai0ys39wl8jBlT0U3WI60BMogQGySCKgIg245KD7AME2y+e/zV+rT7I6M wsypdJz1k0YRuFYoLF+lSa+Ot2NFaNZunVzcfc1toa9eLuflEa1iwkvnFOEbR9SdKAJO 6DtQ== X-Received: by 10.112.171.68 with SMTP id as4mr11898292lbc.64.1441073485421; Mon, 31 Aug 2015 19:11:25 -0700 (PDT) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id b3sm985501lak.26.2015.08.31.19.11.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Aug 2015 19:11:24 -0700 (PDT) References: <55E41499.5030501@yandex.ru> From: Dmitry Gutov Message-ID: <55E5094A.3010108@yandex.ru> Date: Tue, 1 Sep 2015 05:11:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 08/31/2015 08:44 PM, Stefan Monnier wrote: > So we need to change vc-git-mode-line-string to put the branch name > in there. Doesn't seem particularly hard. That sounds like a plan. Any misgivings about this patch? diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el index 9522328..50c6d96 100644 --- a/lisp/vc/vc-git.el +++ b/lisp/vc/vc-git.el @@ -248,26 +248,30 @@ matching the resulting Git log output, and KEYWORDS is a list of (vc-git--state-code diff-letter))) (if (vc-git--empty-db-p) 'added 'up-to-date)))) -(defun vc-git-working-revision (file) +(defun vc-git-working-revision (_file) "Git-specific version of `vc-working-revision'." - (let* (process-file-side-effects - (str (vc-git--run-command-string nil "symbolic-ref" "HEAD"))) - (vc-file-setprop file 'vc-git-detached (null str)) - (if str - (if (string-match "^\\(refs/heads/\\)?\\(.+\\)$" str) - (match-string 2 str) - str) - (vc-git--rev-parse "HEAD")))) + (let (process-file-side-effects) + (vc-git--rev-parse "HEAD"))) + +(defun vc-git--symbolic-ref (file) + (or + (vc-file-getprop file 'vc-git-symbolic-ref) + (let* (process-file-side-effects + (str (vc-git--run-command-string nil "symbolic-ref" "HEAD"))) + (vc-file-setprop file 'vc-git-symbolic-ref + (if str + (if (string-match "^\\(refs/heads/\\)?\\(.+\\)$" str) + (match-string 2 str) + str)))))) (defun vc-git-mode-line-string (file) "Return a string for `vc-mode-line' to put in the mode line for FILE." (let* ((rev (vc-working-revision file)) - (detached (vc-file-getprop file 'vc-git-detached)) + (disp-rev (or (vc-git--symbolic-ref file) + (substring rev 0 7))) (def-ml (vc-default-mode-line-string 'Git file)) (help-echo (get-text-property 0 'help-echo def-ml))) - (propertize (if detached - (substring def-ml 0 (- 7 (length rev))) - def-ml) + (propertize (replace-regexp-in-string (concat rev "\\'") disp-rev def-ml t t) 'help-echo (concat help-echo "\nCurrent revision: " rev)))) (cl-defstruct (vc-git-extra-fileinfo From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Sep 2015 03:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383@debbugs.gnu.org, Jonathan H Received: via spool by 21383-submit@debbugs.gnu.org id=B21383.144107972514854 (code B ref 21383); Tue, 01 Sep 2015 03:56:01 +0000 Received: (at 21383) by debbugs.gnu.org; 1 Sep 2015 03:55:25 +0000 Received: from localhost ([127.0.0.1]:44558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWcfM-0003rW-Nj for submit@debbugs.gnu.org; Mon, 31 Aug 2015 23:55:25 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:50629) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWcfL-0003rO-2N for 21383@debbugs.gnu.org; Mon, 31 Aug 2015 23:55:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AxFgA731xV//rn92hcgxCEAoVVu0CHSwQCAoE8OxIBAQEBAQEBgQpBBYNdAQEEViMQCw4mEhQYDSSIP88jAQEBAQYBAQEBHos6hQUHhC0FtQQjhBQigngBAQE X-IPAS-Result: A0AxFgA731xV//rn92hcgxCEAoVVu0CHSwQCAoE8OxIBAQEBAQEBgQpBBYNdAQEEViMQCw4mEhQYDSSIP88jAQEBAQYBAQEBHos6hQUHhC0FtQQjhBQigngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="162024231" Received: from 104-247-231-250.cpe.teksavvy.com (HELO ceviche.home) ([104.247.231.250]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2015 23:55:22 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 30BF16615C; Mon, 31 Aug 2015 23:55:22 -0400 (EDT) From: Stefan Monnier Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> Date: Mon, 31 Aug 2015 23:55:22 -0400 In-Reply-To: <55E5094A.3010108@yandex.ru> (Dmitry Gutov's message of "Tue, 1 Sep 2015 05:11:22 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > -(defun vc-git-working-revision (file) > +(defun vc-git-working-revision (_file) VC was originally designed so as to separate the VC data from the buffers, so the `file' argument was absolutely indispensable (you can't/shouldn't rely on things like the current-buffer's default-directory). I think nowadays the design has been changed enough that indeed the `file' arg can be dispensed with. The rest looks OK to me, Stefan From unknown Sun Jun 22 11:37:53 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Jonathan H Subject: bug#21383: closed (Re: bug#21383: Static revisions in vc-working-revision) Message-ID: References: <55E59487.1050804@yandex.ru> X-Gnu-PR-Message: they-closed 21383 X-Gnu-PR-Package: emacs Reply-To: 21383@debbugs.gnu.org Date: Tue, 01 Sep 2015 12:06:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1441109162-5771-1" This is a multi-part message in MIME format... ------------=_1441109162-5771-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #21383: Static revisions in vc-working-revision which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 21383@debbugs.gnu.org. --=20 21383: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D21383 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1441109162-5771-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 21383-done) by debbugs.gnu.org; 1 Sep 2015 12:05:36 +0000 Received: from localhost ([127.0.0.1]:44767 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWkJj-0001UP-Ow for submit@debbugs.gnu.org; Tue, 01 Sep 2015 08:05:36 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:36799) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWkJh-0001UG-3o for 21383-done@debbugs.gnu.org; Tue, 01 Sep 2015 08:05:33 -0400 Received: by lbvd4 with SMTP id d4so41218028lbv.3 for <21383-done@debbugs.gnu.org>; Tue, 01 Sep 2015 05:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=0iK7D3otZN4n+jA5XA0idbvrDXQWEKFJfQSNplJkmIY=; b=UY6O3wTHZ5GKa9VOGE2iO2e/5gKEy3c+AzBQLoCDOplodxGX5Y7+LCeHzdL/UdM6+X Fe3ZKrNvNbmKDKOyC+KBgSY8YpCPEdfQLdRnnTWWn81roEmPmK9MxKsK9zM0zZX+FXli U6kNpk70eSED7pr9AN+q7uXBSfrtH6Gx2LR9e5lR7+h2FOKlYXwGlbJAOJ8CNwd3gIx/ L8DPwHWIVy9YYw8FAHiAsdSB5EG5nj0mwJtGjXw8VuQi/lnvJX3gZkI4IZ8/rJJrP32G mfuu3mmkfM8f8ExUOz9joxaoTxy8pFZSGtFe8O5xN6jGIqMR4s2MYgawxybVIF9VABVH bTdg== X-Received: by 10.112.166.106 with SMTP id zf10mr13168612lbb.36.1441109130661; Tue, 01 Sep 2015 05:05:30 -0700 (PDT) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id u3sm4735679laj.31.2015.09.01.05.05.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Sep 2015 05:05:29 -0700 (PDT) Subject: Re: bug#21383: Static revisions in vc-working-revision To: Stefan Monnier References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> From: Dmitry Gutov Message-ID: <55E59487.1050804@yandex.ru> Date: Tue, 1 Sep 2015 15:05:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21383-done Cc: 21383-done@debbugs.gnu.org, Jonathan H X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 09/01/2015 06:55 AM, Stefan Monnier wrote: > VC was originally designed so as to separate the VC data from the > buffers, so the `file' argument was absolutely indispensable (you > can't/shouldn't rely on things like the current-buffer's default-directory). > > I think nowadays the design has been changed enough that indeed the > `file' arg can be dispensed with. I think just the current usage, everywhere, makes it okay. But if I were to inquire of the status of a file in a different repository, that would still fail. We don't don't seem to do that anywhere, though, and supporting that usage would require fixes in multiple places. This patch doesn't change much in this regard: FILE wasn't used for its default-directory even before it. > The rest looks OK to me, Thanks, installed. ------------=_1441109162-5771-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 31 Aug 2015 00:46:03 +0000 Received: from localhost ([127.0.0.1]:43188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWDEY-0003l9-VN for submit@debbugs.gnu.org; Sun, 30 Aug 2015 20:46:03 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46071) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWDEV-0003kg-Qo for submit@debbugs.gnu.org; Sun, 30 Aug 2015 20:46:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWDEU-0003no-8g for submit@debbugs.gnu.org; Sun, 30 Aug 2015 20:45:59 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:41538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWDEU-0003nk-5m for submit@debbugs.gnu.org; Sun, 30 Aug 2015 20:45:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWDET-0000Nw-2N for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 20:45:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWDER-0003nM-Sf for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 20:45:56 -0400 Received: from mail-ig0-x233.google.com ([2607:f8b0:4001:c05::233]:33060) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWDER-0003nG-Lf for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 20:45:55 -0400 Received: by igbuu8 with SMTP id uu8so37608988igb.0 for ; Sun, 30 Aug 2015 17:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=/MTOfMW//GRkVHh3EK2eNsJfUC0tnhLi7XPbIsslLtI=; b=KLd6NGvvQRA8RmE8fZPlFDMJD4FvlITesU6ApS7uU02V9b6A4uLQ3wS7xJKSDu3+Ia E4Y81Zan88LEe5+KExFG7x9AyeBtBm5PVxPOKrKwa1+Ns2dHPrExLvTPLt48h4Tex/tl MhGiTMJhy2yuJtp4xnpOKZQ+VwMAqiDfkl1iVUyHwN0gHZzMIj0bUn/F4fRHa1xgzydo jbyKDLWMX7y5TXHVQ2DqIvhLoFChHNUWazGNk0Vqol/qk6Ni/msKRYOTpI0fJNVahD35 4KvgbTDgZDOPW3BOtSTJ2pctnOraaVroeHJNYknVHZZfCiwcIAxrUd0r0CPe61rNCXzF 8blQ== X-Received: by 10.50.129.99 with SMTP id nv3mr13400719igb.20.1440981954628; Sun, 30 Aug 2015 17:45:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.110.197 with HTTP; Sun, 30 Aug 2015 17:45:25 -0700 (PDT) From: Jonathan H Date: Sun, 30 Aug 2015 17:45:25 -0700 Message-ID: Subject: Static revisions in vc-working-revision To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary=047d7b3a91e688c54b051e90c151 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --047d7b3a91e688c54b051e90c151 Content-Type: multipart/alternative; boundary=047d7b3a91e688c544051e90c14f --047d7b3a91e688c544051e90c14f Content-Type: text/plain; charset=UTF-8 Hello all! I've attached a basic patch that adds an option to vc-working-revision. The option is named *concrete* and if non-nil, it forces vc-working-revision to return a revision name that will not go stale after new revisions are made. This is useful for, e.g. git, where vc-working-revision will just return the branch name, which only refers to the current commit for as long as it's the head of the branch. I'm using this in diff-hl #33 to determine when to refresh the current VC highlighting. I've supplied an implementation for Git, and no-op implementations for all the other backends. For most systems (i.e. all the other VCS systems I know), the value of *concrete *does not matter. If you know a backend that would benefit from a real implementation, please let me know. Also, this is my first patch, so I'm not entirely sure I've got all my ducks in a row. Any comments on that would be great too. Thanks, Jonathan --047d7b3a91e688c544051e90c14f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all!

I've= attached a basic patch that adds an option to vc-working-revision. The opt= ion is named concrete and if non-nil, it forces vc-working-revision = to return a revision name that will not go stale after new revisions are ma= de.

This is useful for, e.g. git, where vc-working-revisi= on will just return the branch name, which only refers to the current commi= t for as long as it's the head of the branch.

I'm= using this in diff= -hl #33 to determine when to refresh the current VC highlighting.
I've supplied an implementation for Git, and no-op impleme= ntations for all the other backends. For most systems (i.e. all the other V= CS systems I know), the value of concrete does not matter. If you kn= ow a backend that would benefit from a real implementation, please let me k= now.

Also, this is my first patch, so I'm = not entirely sure I've got all my ducks in a row. Any comments on that = would be great too.

Thanks,
Jonathan
--047d7b3a91e688c544051e90c14f-- --047d7b3a91e688c54b051e90c151 Content-Type: application/octet-stream; name="0001-Add-CONCRETE-parameter-to-vc-working-revision.patch" Content-Disposition: attachment; filename="0001-Add-CONCRETE-parameter-to-vc-working-revision.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_idugwl8b0 RnJvbSA1ZmM3ZGZmNzYxMDJlYTFlMDk3YmMzOWNiY2ViOGI3ZDcxZGY0NDdkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQeXRob25OdXQgPFB5dGhvbk51dEB1c2Vycy5ub3JlcGx5Lmdp dGh1Yi5jb20+CkRhdGU6IFNhdCwgMjIgQXVnIDIwMTUgMDE6MjU6NDQgKzAwMDAKU3ViamVjdDog W1BBVENIXSBBZGQgQ09OQ1JFVEUgcGFyYW1ldGVyIHRvIHZjLXdvcmtpbmctcmV2aXNpb24KCklm IENPTkNSRVRFIGlzIG5vbi1uaWwsIHRoZSByZXZpc2lvbiB3aWxsIGJlIHRpZWQgdG8gYW4gdW5h bWJpZ3VvdXMgY29tbWl0Cmluc3RlYWQgb2YgdGhlIG5vcm1hbCBzeW1ib2xpYyByZWYuCi0tLQog bGlzcC92Yy92Yy1ienIuZWwgICB8ICAyICstCiBsaXNwL3ZjL3ZjLWN2cy5lbCAgIHwgIDIgKy0K IGxpc3AvdmMvdmMtZ2l0LmVsICAgfCAxMiArKysrKystLS0tLS0KIGxpc3AvdmMvdmMtaGcuZWwg ICAgfCAgMiArLQogbGlzcC92Yy92Yy1ob29rcy5lbCB8IDE4ICsrKysrKysrKysrLS0tLS0tLQog bGlzcC92Yy92Yy1tdG4uZWwgICB8ICAyICstCiBsaXNwL3ZjL3ZjLXJjcy5lbCAgIHwgIDIgKy0K IGxpc3AvdmMvdmMtc2Njcy5lbCAgfCAgMiArLQogbGlzcC92Yy92Yy1zcmMuZWwgICB8ICAyICst CiBsaXNwL3ZjL3ZjLXN2bi5lbCAgIHwgIDIgKy0KIDEwIGZpbGVzIGNoYW5nZWQsIDI1IGluc2Vy dGlvbnMoKyksIDIxIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpc3AvdmMvdmMtYnpyLmVs IGIvbGlzcC92Yy92Yy1ienIuZWwKaW5kZXggNWY4ZGQwYi4uOTUzMTc5ZSAxMDA2NDQKLS0tIGEv bGlzcC92Yy92Yy1ienIuZWwKKysrIGIvbGlzcC92Yy92Yy1ienIuZWwKQEAgLTUzMiw3ICs1MzIs NyBAQCBSZXR1cm5zIG5pbCBpZiB1bmFibGUgdG8gZmluZCB0aGlzIGluZm9ybWF0aW9uLiIKICAg ICAgICAgICAgICAobG9va2luZy1hdCAiWzAtOV0rXDBcXChbXlwwXG5dK1xcKVwwIikKICAgICAg ICAgICAgICAobWF0Y2gtc3RyaW5nIDEpKSkpKSkKIAotKGRlZnVuIHZjLWJ6ci13b3JraW5nLXJl dmlzaW9uIChmaWxlKQorKGRlZnVuIHZjLWJ6ci13b3JraW5nLXJldmlzaW9uIChmaWxlICZvcHRp b25hbCBjb25jcmV0ZSkKICAgKGxldCogKChyb290ZGlyICh2Yy1ienItcm9vdCBmaWxlKSkKICAg ICAgICAgIChicmFuY2gtZm9ybWF0LWZpbGUgKGV4cGFuZC1maWxlLW5hbWUgdmMtYnpyLWFkbWlu LWJyYW5jaC1mb3JtYXQtZmlsZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICByb290ZGlyKSkKZGlmZiAtLWdpdCBhL2xpc3AvdmMvdmMtY3ZzLmVsIGIvbGlz cC92Yy92Yy1jdnMuZWwKaW5kZXggOWE0MTkwNS4uMjkwYjhjYiAxMDA2NDQKLS0tIGEvbGlzcC92 Yy92Yy1jdnMuZWwKKysrIGIvbGlzcC92Yy92Yy1jdnMuZWwKQEAgLTI1OCw3ICsyNTgsNyBAQCBT ZWUgYWxzbyB2YXJpYWJsZSBgdmMtY3ZzLXN0aWNreS1kYXRlLWZvcm1hdC1zdHJpbmcnLiIKICAg ICAgKChudWxsIGNoZWNrb3V0LXRpbWUpICd1bnJlZ2lzdGVyZWQpCiAgICAgICh0ICdlZGl0ZWQp KSkpCiAKLShkZWZ1biB2Yy1jdnMtd29ya2luZy1yZXZpc2lvbiAoZmlsZSkKKyhkZWZ1biB2Yy1j dnMtd29ya2luZy1yZXZpc2lvbiAoZmlsZSAmb3B0aW9uYWwgY29uY3JldGUpCiAgICJDVlMtc3Bl Y2lmaWMgdmVyc2lvbiBvZiBgdmMtd29ya2luZy1yZXZpc2lvbicuIgogICA7OyBUaGVyZSBpcyBu byBuZWVkIHRvIGNvbnN1bHQgUkNTIGhlYWRlcnMgdW5kZXIgQ1ZTLCBiZWNhdXNlIHdlCiAgIDs7 IGdldCB0aGUgd29ya2ZpbGUgdmVyc2lvbiBmb3IgZnJlZSB3aGVuIHdlIHJlY29nbml6ZSB0aGF0 IGEgZmlsZQpkaWZmIC0tZ2l0IGEvbGlzcC92Yy92Yy1naXQuZWwgYi9saXNwL3ZjL3ZjLWdpdC5l bAppbmRleCA5NTIyMzI4Li44NGUyMDI1IDEwMDY0NAotLS0gYS9saXNwL3ZjL3ZjLWdpdC5lbAor KysgYi9saXNwL3ZjL3ZjLWdpdC5lbApAQCAtMjQ4LDE1ICsyNDgsMTUgQEAgbWF0Y2hpbmcgdGhl IHJlc3VsdGluZyBHaXQgbG9nIG91dHB1dCwgYW5kIEtFWVdPUkRTIGlzIGEgbGlzdCBvZgogICAg ICAgICAgICAgKHZjLWdpdC0tc3RhdGUtY29kZSBkaWZmLWxldHRlcikpKQogICAgICAgKGlmICh2 Yy1naXQtLWVtcHR5LWRiLXApICdhZGRlZCAndXAtdG8tZGF0ZSkpKSkKIAotKGRlZnVuIHZjLWdp dC13b3JraW5nLXJldmlzaW9uIChmaWxlKQorKGRlZnVuIHZjLWdpdC13b3JraW5nLXJldmlzaW9u IChmaWxlICZvcHRpb25hbCBjb25jcmV0ZSkKICAgIkdpdC1zcGVjaWZpYyB2ZXJzaW9uIG9mIGB2 Yy13b3JraW5nLXJldmlzaW9uJy4iCiAgIChsZXQqIChwcm9jZXNzLWZpbGUtc2lkZS1lZmZlY3Rz Ci0gICAgICAgICAoc3RyICh2Yy1naXQtLXJ1bi1jb21tYW5kLXN0cmluZyBuaWwgInN5bWJvbGlj LXJlZiIgIkhFQUQiKSkpCisgICAgICAgICAgKHN0ciAodmMtZ2l0LS1ydW4tY29tbWFuZC1zdHJp bmcgbmlsICJzeW1ib2xpYy1yZWYiICJIRUFEIikpKQogICAgICh2Yy1maWxlLXNldHByb3AgZmls ZSAndmMtZ2l0LWRldGFjaGVkIChudWxsIHN0cikpCi0gICAgKGlmIHN0cgotICAgICAgICAoaWYg KHN0cmluZy1tYXRjaCAiXlxcKHJlZnMvaGVhZHMvXFwpP1xcKC4rXFwpJCIgc3RyKQotICAgICAg ICAgICAgKG1hdGNoLXN0cmluZyAyIHN0cikKLSAgICAgICAgICBzdHIpCisgICAgKGlmIChhbmQg c3RyIChub3QgY29uY3JldGUpKQorICAgICAgKGlmIChzdHJpbmctbWF0Y2ggIl5cXChyZWZzL2hl YWRzL1xcKT9cXCguK1xcKSQiIHN0cikKKyAgICAgICAgKG1hdGNoLXN0cmluZyAyIHN0cikKKyAg ICAgICAgc3RyKQogICAgICAgKHZjLWdpdC0tcmV2LXBhcnNlICJIRUFEIikpKSkKIAogKGRlZnVu IHZjLWdpdC1tb2RlLWxpbmUtc3RyaW5nIChmaWxlKQpkaWZmIC0tZ2l0IGEvbGlzcC92Yy92Yy1o Zy5lbCBiL2xpc3AvdmMvdmMtaGcuZWwKaW5kZXggZjYzNGUyZS4uZWVlOGM4NSAxMDA2NDQKLS0t IGEvbGlzcC92Yy92Yy1oZy5lbAorKysgYi9saXNwL3ZjL3ZjLWhnLmVsCkBAIC0yMzcsNyArMjM3 LDcgQEAgaGlnaGxpZ2h0aW5nIHRoZSBMb2cgVmlldyBidWZmZXIuIgogCSAoKGVxIHN0YXRlID9D KSAndXAtdG8tZGF0ZSkgOzsgT2xkZXIgbWVyY3VyaWFsIHZlcnNpb25zIHVzZSB0aGlzLgogCSAo dCAndXAtdG8tZGF0ZSkpKSkpKQogCi0oZGVmdW4gdmMtaGctd29ya2luZy1yZXZpc2lvbiAoZmls ZSkKKyhkZWZ1biB2Yy1oZy13b3JraW5nLXJldmlzaW9uIChmaWxlICZvcHRpb25hbCBjb25jcmV0 ZSkKICAgIkhnLXNwZWNpZmljIHZlcnNpb24gb2YgYHZjLXdvcmtpbmctcmV2aXNpb24nLiIKICAg KG9yIChpZ25vcmUtZXJyb3JzCiAgICAgICAgICh3aXRoLW91dHB1dC10by1zdHJpbmcKZGlmZiAt LWdpdCBhL2xpc3AvdmMvdmMtaG9va3MuZWwgYi9saXNwL3ZjL3ZjLWhvb2tzLmVsCmluZGV4IGJh ZTk5MTkuLjUwNGVmYjkgMTAwNjQ0Ci0tLSBhL2xpc3AvdmMvdmMtaG9va3MuZWwKKysrIGIvbGlz cC92Yy92Yy1ob29rcy5lbApAQCAtNDkwLDE1ICs0OTAsMTkgQEAgc3RhdHVzIG9mIHRoaXMgZmls ZS4gIE90aGVyd2lzZSwgdGhlIHZhbHVlIHJldHVybmVkIGlzIG9uZSBvZjoKICAgIkNvbnZlbmll bmNlIGZ1bmN0aW9uIHRoYXQgY2hlY2tzIHdoZXRoZXIgYHZjLXN0YXRlJyBvZiBGSUxFIGlzIGB1 cC10by1kYXRlJy4iCiAgIChlcSAodmMtc3RhdGUgZmlsZSkgJ3VwLXRvLWRhdGUpKQogCi0oZGVm dW4gdmMtd29ya2luZy1yZXZpc2lvbiAoZmlsZSAmb3B0aW9uYWwgYmFja2VuZCkKKyhkZWZ1biB2 Yy13b3JraW5nLXJldmlzaW9uIChmaWxlICZvcHRpb25hbCBiYWNrZW5kIGNvbmNyZXRlKQogICAi UmV0dXJuIHRoZSByZXBvc2l0b3J5IHZlcnNpb24gZnJvbSB3aGljaCBGSUxFIHdhcyBjaGVja2Vk IG91dC4KLUlmIEZJTEUgaXMgbm90IHJlZ2lzdGVyZWQsIHRoaXMgZnVuY3Rpb24gYWx3YXlzIHJl dHVybnMgbmlsLiIKLSAgKG9yICh2Yy1maWxlLWdldHByb3AgZmlsZSAndmMtd29ya2luZy1yZXZp c2lvbikKK0lmIEZJTEUgaXMgbm90IHJlZ2lzdGVyZWQsIHRoaXMgZnVuY3Rpb24gYWx3YXlzIHJl dHVybnMgbmlsLgorSWYgQ09OQ1JFVEUgaXMgbm9uLW5pbCwgdGhlIHJldmlzaW9uIHdpbGwgYmUg dGllZCB0byBhbiB1bmFtYmlndW91cyBjb21taXQKK2luc3RlYWQgb2YgdGhlIG5vcm1hbCBzeW1i b2xpYyByZWYuIgorICAoaWYgY29uY3JldGUKKyAgICAodmMtY2FsbC1iYWNrZW5kIGJhY2tlbmQg J3dvcmtpbmctcmV2aXNpb24gZmlsZSB0KQorICAgIChvciAodmMtZmlsZS1nZXRwcm9wIGZpbGUg J3ZjLXdvcmtpbmctcmV2aXNpb24pCiAgICAgICAocHJvZ24KLQkoc2V0cSBiYWNrZW5kIChvciBi YWNrZW5kICh2Yy1yZXNwb25zaWJsZS1iYWNrZW5kIGZpbGUpKSkKLQkod2hlbiBiYWNrZW5kCi0J ICAodmMtZmlsZS1zZXRwcm9wIGZpbGUgJ3ZjLXdvcmtpbmctcmV2aXNpb24KLQkJCSAgICh2Yy1j YWxsLWJhY2tlbmQgYmFja2VuZCAnd29ya2luZy1yZXZpc2lvbiBmaWxlKSkpKSkpCisgICAgICAg IChzZXRxIGJhY2tlbmQgKG9yIGJhY2tlbmQgKHZjLXJlc3BvbnNpYmxlLWJhY2tlbmQgZmlsZSkp KQorICAgICAgICAod2hlbiBiYWNrZW5kCisgICAgICAgICAgKHZjLWZpbGUtc2V0cHJvcCBmaWxl ICd2Yy13b3JraW5nLXJldmlzaW9uCisgICAgICAgICAgICAodmMtY2FsbC1iYWNrZW5kIGJhY2tl bmQgJ3dvcmtpbmctcmV2aXNpb24gZmlsZSkpKSkpKSkKIAogOzsgQmFja3dhcmQgY29tcGF0aWJp bGl0eS4KIChkZWZpbmUtb2Jzb2xldGUtZnVuY3Rpb24tYWxpYXMKZGlmZiAtLWdpdCBhL2xpc3Av dmMvdmMtbXRuLmVsIGIvbGlzcC92Yy92Yy1tdG4uZWwKaW5kZXggNjg1ZWYzYi4uNjNlZmI5ZiAx MDA2NDQKLS0tIGEvbGlzcC92Yy92Yy1tdG4uZWwKKysrIGIvbGlzcC92Yy92Yy1tdG4uZWwKQEAg LTE0Nyw3ICsxNDcsNyBAQCBzd2l0Y2hlcy4iCiAgICh2Yy1ydW4tZGVsYXllZAogICAgKHZjLW10 bi1hZnRlci1kaXItc3RhdHVzIHVwZGF0ZS1mdW5jdGlvbikpKQogCi0oZGVmdW4gdmMtbXRuLXdv cmtpbmctcmV2aXNpb24gKGZpbGUpCisoZGVmdW4gdmMtbXRuLXdvcmtpbmctcmV2aXNpb24gKGZp bGUgJm9wdGlvbmFsIGNvbmNyZXRlKQogICA7OyBJZiBgbXRuJyBmYWlscyBvciByZXR1cm5zIHN0 YXR1cz4wLCBvciBpZiB0aGUgc2VhcmNoIGZhaWxzLCBqdXN0CiAgIDs7IHJldHVybiBuaWwuCiAg IChpZ25vcmUtZXJyb3JzCmRpZmYgLS1naXQgYS9saXNwL3ZjL3ZjLXJjcy5lbCBiL2xpc3AvdmMv dmMtcmNzLmVsCmluZGV4IDcxZmZhNTUuLjVhNWVkNzYgMTAwNjQ0Ci0tLSBhL2xpc3AvdmMvdmMt cmNzLmVsCisrKyBiL2xpc3AvdmMvdmMtcmNzLmVsCkBAIC0xNjgsNyArMTY4LDcgQEAgRm9yIGEg ZGVzY3JpcHRpb24gb2YgcG9zc2libGUgdmFsdWVzLCBzZWUgYHZjLWNoZWNrLW1hc3Rlci10ZW1w bGF0ZXMnLiIKIAkgIChwdXNoIChsaXN0IGZyZWwgc3RhdGUpIHJlc3VsdCkpKSkKICAgICAoZnVu Y2FsbCB1cGRhdGUtZnVuY3Rpb24gcmVzdWx0KSkpCiAKLShkZWZ1biB2Yy1yY3Mtd29ya2luZy1y ZXZpc2lvbiAoZmlsZSkKKyhkZWZ1biB2Yy1yY3Mtd29ya2luZy1yZXZpc2lvbiAoZmlsZSAmb3B0 aW9uYWwgY29uY3JldGUpCiAgICJSQ1Mtc3BlY2lmaWMgdmVyc2lvbiBvZiBgdmMtd29ya2luZy1y ZXZpc2lvbicuIgogICAob3IgKGFuZCB2Yy1jb25zdWx0LWhlYWRlcnMKICAgICAgICAgICAgKHZj LXJjcy1jb25zdWx0LWhlYWRlcnMgZmlsZSkKZGlmZiAtLWdpdCBhL2xpc3AvdmMvdmMtc2Njcy5l bCBiL2xpc3AvdmMvdmMtc2Njcy5lbAppbmRleCA4ZDhkOWU4Li5mN2ZkYjczIDEwMDY0NAotLS0g YS9saXNwL3ZjL3ZjLXNjY3MuZWwKKysrIGIvbGlzcC92Yy92Yy1zY2NzLmVsCkBAIC0xNDcsNyAr MTQ3LDcgQEAgRm9yIGEgZGVzY3JpcHRpb24gb2YgcG9zc2libGUgdmFsdWVzLCBzZWUgYHZjLWNo ZWNrLW1hc3Rlci10ZW1wbGF0ZXMnLiIKIAogKGF1dG9sb2FkICd2Yy1tYXN0ZXItbmFtZSAidmMt ZmlsZXdpc2UiKQogCi0oZGVmdW4gdmMtc2Njcy13b3JraW5nLXJldmlzaW9uIChmaWxlKQorKGRl ZnVuIHZjLXNjY3Mtd29ya2luZy1yZXZpc2lvbiAoZmlsZSAmb3B0aW9uYWwgY29uY3JldGUpCiAg ICJTQ0NTLXNwZWNpZmljIHZlcnNpb24gb2YgYHZjLXdvcmtpbmctcmV2aXNpb24nLiIKICAgKHdo ZW4gKGFuZCAoZmlsZS1yZWd1bGFyLXAgZmlsZSkgKHZjLW1hc3Rlci1uYW1lIGZpbGUpKQogICAg ICh3aXRoLXRlbXAtYnVmZmVyCmRpZmYgLS1naXQgYS9saXNwL3ZjL3ZjLXNyYy5lbCBiL2xpc3Av dmMvdmMtc3JjLmVsCmluZGV4IGQ5YWExYjEuLmQyZGQ1MDUgMTAwNjQ0Ci0tLSBhL2xpc3AvdmMv dmMtc3JjLmVsCisrKyBiL2xpc3AvdmMvdmMtc3JjLmVsCkBAIC0xOTgsNyArMTk4LDcgQEAgVGhp cyBmdW5jdGlvbiBkaWZmZXJzIGZyb20gdmMtZG8tY29tbWFuZCBpbiB0aGF0IGl0IGludm9rZXMg YHZjLXNyYy1wcm9ncmFtJy4iCiAJICAgKHNldHEgZmlsZS1saXN0IChjb25zICItLSIgZmlsZS1v ci1saXN0KSkpKQogICAgIChhcHBseSAndmMtZG8tY29tbWFuZCAob3IgYnVmZmVyICIqdmMqIikg MCB2Yy1zcmMtcHJvZ3JhbSBmaWxlLWxpc3QgZmxhZ3MpKSkKIAotKGRlZnVuIHZjLXNyYy13b3Jr aW5nLXJldmlzaW9uIChmaWxlKQorKGRlZnVuIHZjLXNyYy13b3JraW5nLXJldmlzaW9uIChmaWxl ICZvcHRpb25hbCBjb25jcmV0ZSkKICAgIlNSQy1zcGVjaWZpYyB2ZXJzaW9uIG9mIGB2Yy13b3Jr aW5nLXJldmlzaW9uJy4iCiAgIChsZXQgKChyZXN1bHQgKGlnbm9yZS1lcnJvcnMKIAkJICAod2l0 aC1vdXRwdXQtdG8tc3RyaW5nCmRpZmYgLS1naXQgYS9saXNwL3ZjL3ZjLXN2bi5lbCBiL2xpc3Av dmMvdmMtc3ZuLmVsCmluZGV4IDhkNmVhZTUuLjAxY2IxZTQgMTAwNjQ0Ci0tLSBhL2xpc3AvdmMv dmMtc3ZuLmVsCisrKyBiL2xpc3AvdmMvdmMtc3ZuLmVsCkBAIC0yNDAsNyArMjQwLDcgQEAgUkVT VUxUIGlzIGEgbGlzdCBvZiBjb25zZXMgKEZJTEUgLiBTVEFURSkgZm9yIGRpcmVjdG9yeSBESVIu IgogCSAgICAgKHByb3BlcnRpemUgcmVwbyAnZmFjZSAnZm9udC1sb2NrLXZhcmlhYmxlLW5hbWUt ZmFjZSkpKQogCSAgICh0ICIiKSkpKSkKIAotKGRlZnVuIHZjLXN2bi13b3JraW5nLXJldmlzaW9u IChmaWxlKQorKGRlZnVuIHZjLXN2bi13b3JraW5nLXJldmlzaW9uIChmaWxlICZvcHRpb25hbCBj b25jcmV0ZSkKICAgIlNWTi1zcGVjaWZpYyB2ZXJzaW9uIG9mIGB2Yy13b3JraW5nLXJldmlzaW9u Jy4iCiAgIDs7IFRoZXJlIGlzIG5vIG5lZWQgdG8gY29uc3VsdCBSQ1MgaGVhZGVycyB1bmRlciBT Vk4sIGJlY2F1c2Ugd2UKICAgOzsgZ2V0IHRoZSB3b3JrZmlsZSB2ZXJzaW9uIGZvciBmcmVlIHdo ZW4gd2UgcmVjb2duaXplIHRoYXQgYSBmaWxlCi0tIAoyLjUuMAoK --047d7b3a91e688c54b051e90c151-- ------------=_1441109162-5771-1-- From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Sep 2015 15:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144112234826251 (code D ref 21383); Tue, 01 Sep 2015 15:46:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 1 Sep 2015 15:45:48 +0000 Received: from localhost ([127.0.0.1]:45234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWnkq-0006pK-Ds for submit@debbugs.gnu.org; Tue, 01 Sep 2015 11:45:48 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:34120) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWnko-0006pC-EC for 21383-done@debbugs.gnu.org; Tue, 01 Sep 2015 11:45:47 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t81Fjhp3008333; Tue, 1 Sep 2015 11:45:43 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 7328F6615C; Tue, 1 Sep 2015 11:45:43 -0400 (EDT) From: Stefan Monnier Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> Date: Tue, 01 Sep 2015 11:45:43 -0400 In-Reply-To: <55E59487.1050804@yandex.ru> (Dmitry Gutov's message of "Tue, 1 Sep 2015 15:05:27 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5416=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5416> : inlines <3733> : streams <1498130> : uri <2030097> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > I think just the current usage, everywhere, makes it okay. But if I were to > inquire of the status of a file in a different repository, that would still > fail. We don't don't seem to do that anywhere, though, and supporting that > usage would require fixes in multiple places. > This patch doesn't change much in this regard: FILE wasn't used for its > default-directory even before it. That's right. I was just pointing out this change in VC's practice. I think the current practice is not well documented (maybe not completely well defined either). Stefan From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Sep 2015 15:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144112288927029 (code D ref 21383); Tue, 01 Sep 2015 15:55:01 +0000 Received: (at 21383-done) by debbugs.gnu.org; 1 Sep 2015 15:54:49 +0000 Received: from localhost ([127.0.0.1]:45243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWntZ-00071t-86 for submit@debbugs.gnu.org; Tue, 01 Sep 2015 11:54:49 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:38731) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWntX-00071l-7b for 21383-done@debbugs.gnu.org; Tue, 01 Sep 2015 11:54:47 -0400 Received: by wiclp12 with SMTP id lp12so35728688wic.1 for <21383-done@debbugs.gnu.org>; Tue, 01 Sep 2015 08:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=uLEwSIH7WVg1nwoax34abo7bSkXPkrcnW49+wi9WXWY=; b=Zwap4wMwL2by90NLytIcdhESDTm1hU6bWUNkpIVEmjsfOOAPqyejGSbXBZt1bXMf1D 2LrEmscdFMLyq/eC5zyn7wd7GaaJCJGwMiZyzIvK4l03gDlfRuYUI8uJokYIkmfze0iU 8sP6RtDefAmrHV+PBcdwitcq2vykkWZU1LaG2zHYXH92rjSBY45+AEgYNKUnLs+Shw2s ZtldqXAh4FO7uYIh8wbXQFh9jeunhfx846uZ6tbtjXfgOoSsal5tblrAjbrseNlqPwS+ 0+/AWIdss03yaKqGBISx/mHGG1VotUBzkVv2S7CsbokM0jyj0K88T9svkw1c2B7tVirk pnrw== X-Received: by 10.180.231.40 with SMTP id td8mr4342425wic.9.1441122886512; Tue, 01 Sep 2015 08:54:46 -0700 (PDT) Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id x6sm3389794wiy.6.2015.09.01.08.54.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Sep 2015 08:54:45 -0700 (PDT) References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> From: Dmitry Gutov Message-ID: <55E5CA42.1080005@yandex.ru> Date: Tue, 1 Sep 2015 18:54:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 09/01/2015 06:45 PM, Stefan Monnier wrote: > That's right. I was just pointing out this change in VC's practice. > I think the current practice is not well documented (maybe not > completely well defined either). I'd rather not document it yet: officially limiting API's applicability is not ideal. Rather let's wait for a report from someone who triggers this limitation of vc-git and then see if we want to support their use case. From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Sep 2015 16:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144112638132243 (code D ref 21383); Tue, 01 Sep 2015 16:53:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 1 Sep 2015 16:53:01 +0000 Received: from localhost ([127.0.0.1]:45301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWont-0008Nw-HH for submit@debbugs.gnu.org; Tue, 01 Sep 2015 12:53:01 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:44502) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWonr-0008Nn-6e for 21383-done@debbugs.gnu.org; Tue, 01 Sep 2015 12:52:59 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t81Gqu0u029686; Tue, 1 Sep 2015 12:52:57 -0400 Received: by ceviche.home (Postfix, from userid 20848) id B54346615C; Tue, 1 Sep 2015 12:52:56 -0400 (EDT) From: Stefan Monnier Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> Date: Tue, 01 Sep 2015 12:52:56 -0400 In-Reply-To: <55E5CA42.1080005@yandex.ru> (Dmitry Gutov's message of "Tue, 1 Sep 2015 18:54:42 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered GEN_SPAM_FEATRE=0.2, RV5416=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5416> : inlines <3733> : streams <1498155> : uri <2030140> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > Rather let's wait for a report from someone who triggers this limitation of > vc-git and then see if we want to support their use case. I think it goes much further than vc-git. Rather, it permeates most of the VC code. Stefan From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Sep 2015 17:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.14411282252589 (code D ref 21383); Tue, 01 Sep 2015 17:24:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 1 Sep 2015 17:23:45 +0000 Received: from localhost ([127.0.0.1]:45322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWpHc-0000fg-Mz for submit@debbugs.gnu.org; Tue, 01 Sep 2015 13:23:44 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:36636) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWpHa-0000fW-KM for 21383-done@debbugs.gnu.org; Tue, 01 Sep 2015 13:23:43 -0400 Received: by wibz8 with SMTP id z8so39894804wib.1 for <21383-done@debbugs.gnu.org>; Tue, 01 Sep 2015 10:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=+yq2+Ee1esbruHbQ01BrLiFN21gwQJ29FGZ6rHUgHzQ=; b=uFrFp9zdC/Vact3VQ884KeT1441faQP7iuVLDZc/gYl9U5YvVGfxsR6lH9nABtrAWq HbLFVbJY99E8Y1hq8m2VsZTDLYGblGo1yGStAafKIBsTfVkDgwyb0T1D/yV5S2wgE8F3 LelKQiPmCugnuPSOAvcXyRbbIPPNI6OWc62rOtxvoB9ONf26i3NEjB4m6xkIZ4aSGo5s nTBiW/hN+f6yQZOhgqdig00ra3+v5X1Jb2O/ttO4e4c7hmAnNDdKfB+rDplZB5WTyCjC pOsrDErLgUqNweq8FY0WDgPAREGzS9JjrTVVpGcJ8a3sIT00n6IX4jBgJ+i1CVecZHxR hi7Q== X-Received: by 10.194.81.169 with SMTP id b9mr2673125wjy.3.1441128222061; Tue, 01 Sep 2015 10:23:42 -0700 (PDT) Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id ne7sm3720041wic.12.2015.09.01.10.23.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Sep 2015 10:23:41 -0700 (PDT) References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> From: Dmitry Gutov Message-ID: <55E5DF1A.9010902@yandex.ru> Date: Tue, 1 Sep 2015 20:23:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 09/01/2015 07:52 PM, Stefan Monnier wrote: > I think it goes much further than vc-git. > Rather, it permeates most of the VC code. Maybe you see it better. I only imagined the problem limited to the non-file-granularity backends. And we can't simply remove the FILE argument in many backend commands: it's often used for vc-file-get/setprop. From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Sep 2015 03:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144116580811069 (code D ref 21383); Wed, 02 Sep 2015 03:51:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 2 Sep 2015 03:50:08 +0000 Received: from localhost ([127.0.0.1]:45758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWz3o-0002sT-Dh for submit@debbugs.gnu.org; Tue, 01 Sep 2015 23:50:08 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:64213) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWz3m-0002sK-9L for 21383-done@debbugs.gnu.org; Tue, 01 Sep 2015 23:50:06 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AyFgA731xV//rn92hcgxCEAoVVu0CHSwQCAoE8OhMBAQEBAQEBgQpBBYNdAQEDAVYjBQsLDiYSFBgNJIg3CM8jAQEBAQYBAQEBHos6hCxZB4QtAQSQNKRQI4Fmgi4igTSBRAEBAQ X-IPAS-Result: A0AyFgA731xV//rn92hcgxCEAoVVu0CHSwQCAoE8OhMBAQEBAQEBgQpBBYNdAQEDAVYjBQsLDiYSFBgNJIg3CM8jAQEBAQYBAQEBHos6hCxZB4QtAQSQNKRQI4Fmgi4igTSBRAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="162126074" Received: from 104-247-231-250.cpe.teksavvy.com (HELO fmsmemgm.homelinux.net) ([104.247.231.250]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Sep 2015 23:50:05 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 2F91BAE064; Tue, 1 Sep 2015 23:50:05 -0400 (EDT) From: Stefan Monnier Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> Date: Tue, 01 Sep 2015 23:50:05 -0400 In-Reply-To: <55E5DF1A.9010902@yandex.ru> (Dmitry Gutov's message of "Tue, 1 Sep 2015 20:23:38 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Maybe you see it better. I only imagined the problem limited to the > non-file-granularity backends. You mean like most current backends? ;-) > And we can't simply remove the FILE argument in many backend commands: it's > often used for vc-file-get/setprop. I know. In any case, it's not that bad: it works. But there's something fishy that will surely bite at some point. Maybe those FILE args should be redefined to be relative to default-directory (and can't use things like "../.."). Stefan From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Sep 2015 10:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144119095716594 (code D ref 21383); Wed, 02 Sep 2015 10:50:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 2 Sep 2015 10:49:17 +0000 Received: from localhost ([127.0.0.1]:45972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZX5bR-0004JZ-3q for submit@debbugs.gnu.org; Wed, 02 Sep 2015 06:49:17 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:37759) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZX5bP-0004JS-Si for 21383-done@debbugs.gnu.org; Wed, 02 Sep 2015 06:49:16 -0400 Received: by wicfx3 with SMTP id fx3so14450377wic.0 for <21383-done@debbugs.gnu.org>; Wed, 02 Sep 2015 03:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=szqn8GT72NOZhCd/RsYmnBTCOZuxNloL4goNbPinlYk=; b=r8Sd5W1d3SPEmvIp+Swe5Lds/1plJSlkJlhJ8MwduPea7l6/XGq1NcHcuFoUSbX8AQ CPy8g8gnzAFjZqEYMD2aa5HnOrWSpexe7NOSLFgk0LvbCTsoIS/tBb6JfVKLqKxPZRC5 4DNgDCLzw9koc0P9XEU16OC3VFNvIhRxwQqb/E5j1h2svEASt9yoTLshiVvo/yDVfXhj nuSk0ZqRlU7Jb9sJRkFMqAgGWhtKSCMhau+u588wZ9D1OTyoOWKTGx8koHWE9BhDrLfh E7x2U6KlPjQmdCUtHh85KQX0SgExzr6Mx0j6VkxVfU9jAnBTmoSjDT1rISlbmO3mpxPo HYdg== X-Received: by 10.181.12.5 with SMTP id em5mr3365924wid.67.1441190955121; Wed, 02 Sep 2015 03:49:15 -0700 (PDT) Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id hr17sm2960994wib.16.2015.09.02.03.49.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Sep 2015 03:49:14 -0700 (PDT) References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> From: Dmitry Gutov Message-ID: <55E6D426.10105@yandex.ru> Date: Wed, 2 Sep 2015 13:49:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 09/02/2015 06:50 AM, Stefan Monnier wrote: >> Maybe you see it better. I only imagined the problem limited to the >> non-file-granularity backends. > > You mean like most current backends? ;-) Yes. But as long as its only limited to the backends (and can be fixed there), as opposed to being inherently present in vc.el, log-edit.el, etc, it's less of a problem. >> And we can't simply remove the FILE argument in many backend commands: it's >> often used for vc-file-get/setprop. > > I know. > > In any case, it's not that bad: it works. But there's something fishy > that will surely bite at some point. Maybe those FILE args should be > redefined to be relative to default-directory (and can't use things like > "../.."). vc-file-setprop won't work on a relative path. Or shouldn't, at least. And are you talking about FILE arg to vc-status, or e.g. vc-git-status? If vc-status requires the path to be relative, that will complicate the consumer interface (now I have to worry about producing the relative path). If vc-status will be responsible for that before calling vc-git-status, it won't work in file-granular backends. Anyway, why would we want that extra call, even if it's cached? And vc-git-working-revision won't care if FILE is absolute or relative, which is the crux of the problem. I'd rather backends like Git, if we're going to fix this, used FILE's parent directory to change default-directory temporarily before calling Git. From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Jonathan H Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Sep 2015 22:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383-done@debbugs.gnu.org, Stefan Monnier Received: via spool by 21383-done@debbugs.gnu.org id=D21383.14412338745311 (code D ref 21383); Wed, 02 Sep 2015 22:45:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 2 Sep 2015 22:44:34 +0000 Received: from localhost ([127.0.0.1]:47031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXGld-0001Nb-Lx for submit@debbugs.gnu.org; Wed, 02 Sep 2015 18:44:34 -0400 Received: from mail-ig0-f175.google.com ([209.85.213.175]:37848) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXGlb-0001NR-9L for 21383-done@debbugs.gnu.org; Wed, 02 Sep 2015 18:44:32 -0400 Received: by igbni9 with SMTP id ni9so26174448igb.0 for <21383-done@debbugs.gnu.org>; Wed, 02 Sep 2015 15:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xsEKr3zp4tpkEsC9uRBf4sFQn0iCWD4++sOL/5YEPAA=; b=cTImdw/cVgc+L2xdRfvKZCbcqkuRSZA+Y0zXvEvQnNzpiJZR++gsEWgqR2AqIXcweo mCGmhQ3M/k+tenodoRuLFZ8vVfwqZPk5CJHbNTAbrcCgEMKzbbHjqrPMiTKIPcSzcmi1 BKXPt+Lye5cI0lW+RuMRJ0Ri1hfPd8+uW1ADIiuoKpGP6a9B8Ly1TSmrNepnKvet6974 M8wW9KDgBr78EgCM+BzG/OptBZKxOKekFqmUXjjtJEoNSnyDRlGm6wYHmUR9MP6ZQqm0 laLLW6t/cTHmYX++beWoVE3sM5UPcPacPP2mIYKzsQDNwZTge3J4FbH8hc3undtq4Ue4 DI5Q== X-Received: by 10.50.98.7 with SMTP id ee7mr7426214igb.13.1441233870480; Wed, 02 Sep 2015 15:44:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.110.197 with HTTP; Wed, 2 Sep 2015 15:44:01 -0700 (PDT) In-Reply-To: <55E6D426.10105@yandex.ru> References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> From: Jonathan H Date: Wed, 2 Sep 2015 15:44:01 -0700 Message-ID: Content-Type: multipart/alternative; boundary=047d7b2e10d1e36bb3051ecb687f X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7b2e10d1e36bb3051ecb687f Content-Type: text/plain; charset=UTF-8 Something seems a bit amiss with the current patch. I'm using (vc-working-revision buffer-file-name (vc-responsible-backend buffer-file-name)) to determine the current working revision. As far as I can tell, vc-working-revision will cache the current working revision in a file property, but it doesn't know when to invalidate the cache, so the results can be stale. In fact, in the specific case of git, you probably can't get any faster than a rev-parse anyway, so caching doesn't make much sense. I have a sneaking suspicion that git isn't the only backend where this can happen. Thanks, Jonathan On Wed, Sep 2, 2015 at 3:49 AM, Dmitry Gutov wrote: > On 09/02/2015 06:50 AM, Stefan Monnier wrote: > >> Maybe you see it better. I only imagined the problem limited to the >>> non-file-granularity backends. >>> >> >> You mean like most current backends? ;-) >> > > Yes. But as long as its only limited to the backends (and can be fixed > there), as opposed to being inherently present in vc.el, log-edit.el, etc, > it's less of a problem. > > And we can't simply remove the FILE argument in many backend commands: it's >>> often used for vc-file-get/setprop. >>> >> >> I know. >> >> In any case, it's not that bad: it works. But there's something fishy >> that will surely bite at some point. Maybe those FILE args should be >> redefined to be relative to default-directory (and can't use things like >> "../.."). >> > > vc-file-setprop won't work on a relative path. Or shouldn't, at least. > > And are you talking about FILE arg to vc-status, or e.g. vc-git-status? If > vc-status requires the path to be relative, that will complicate the > consumer interface (now I have to worry about producing the relative path). > If vc-status will be responsible for that before calling vc-git-status, it > won't work in file-granular backends. Anyway, why would we want that extra > call, even if it's cached? > > And vc-git-working-revision won't care if FILE is absolute or relative, > which is the crux of the problem. I'd rather backends like Git, if we're > going to fix this, used FILE's parent directory to change default-directory > temporarily before calling Git. > --047d7b2e10d1e36bb3051ecb687f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Something seems a bit amiss with the curren= t patch.

I'm using (vc-working-revision buffer-file-n= ame (vc-responsible-backend buffer-file-name)) to determine the current wor= king revision.

As far as I can tell, vc-working-rev= ision will cache the current working revision in a file property, but it do= esn't know when to invalidate the cache, so the results can be stale. I= n fact, in the specific case of git, you probably can't get any faster = than a rev-parse anyway, so caching doesn't make much sense.

I have a sneaking suspicion that git isn't the only backend whe= re this can happen.

Thanks,
Jonathan



On Wed, Sep 2, 2015 at 3:49 AM, Dmitry Gutov <dgutov@yande= x.ru> wrote:
On 09/02/2015 06:50 AM, Stefan Monnier wrote:
Maybe you see it better.=C2=A0 I only imagined the problem limited to the non-file-granularity backends.

You mean like most current backends? ;-)

 Yes. But as long as its only limited to the backends (and can be fixed ther= e), as opposed to being inherently present in vc.el, log-edit.el, etc, it&#= 39;s less of a problem.

And we can't simply remove the FILE argument in many backend commands: = it's
often used for vc-file-get/setprop.

I know.

In any case, it's not that bad: it works.=C2=A0 But there's somethi= ng fishy
that will surely bite at some point.=C2=A0 Maybe those FILE args should be<= br> redefined to be relative to default-directory (and can't use things lik= e
"../..").

 vc-file-setprop won't work on a relative path. Or shouldn't, at lea= st.

And are you talking about FILE arg to vc-status, or e.g. vc-git-status? If = vc-status requires the path to be relative, that will complicate the consum= er interface (now I have to worry about producing the relative path). If vc= -status will be responsible for that before calling vc-git-status, it won&#= 39;t work in file-granular backends. Anyway, why would we want that extra c= all, even if it's cached?

And vc-git-working-revision won't care if FILE is absolute or relative,= which is the crux of the problem. I'd rather backends like Git, if we&= #39;re going to fix this, used FILE's parent directory to change defaul= t-directory temporarily before calling Git.

--047d7b2e10d1e36bb3051ecb687f-- From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Sep 2015 12:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jonathan H Cc: 21383-done@debbugs.gnu.org Received: via spool by 21383-done@debbugs.gnu.org id=D21383.14412850062717 (code D ref 21383); Thu, 03 Sep 2015 12:57:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 3 Sep 2015 12:56:46 +0000 Received: from localhost ([127.0.0.1]:47355 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXU4L-0000hk-Gh for submit@debbugs.gnu.org; Thu, 03 Sep 2015 08:56:45 -0400 Received: from mail-wi0-f176.google.com ([209.85.212.176]:36415) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXU4H-0000hW-8G for 21383-done@debbugs.gnu.org; Thu, 03 Sep 2015 08:56:42 -0400 Received: by wibz8 with SMTP id z8so97980984wib.1 for <21383-done@debbugs.gnu.org>; Thu, 03 Sep 2015 05:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=KLYEKAXXlIQQwfzbt3OWZWMw4JfFgGjNeIHJDRTSTjs=; b=hBvWt19TxeAwdhWfYBvQ/teXtdv622IMzHIjKYqgk8y3iROZvFl5YfDPPerY2s6/8R ZfBarAIEpM/e/eA0zetk8wxXHu7WCf55L2nm+yHiwExdMCFVm34/qg/MwOFey9s89NZC oAg+0iYIK2wLMrg4+uQmAD87vKlJ6SJmD50Of2ww3v5JuTvYRJ1tyK6LtR3sFeolXuXN i0XPHtK1tnXhFdGCgL/udwQMjfSmjWCc5TFbYdRPBAcTCSBzLQs/PTC8PNenCawMa5u5 qSFJrE/LjYp7HoAaxIAz6Unnui2XrTLiRi7TkckhMtbbXFHi6fW52K1WCh4Ijd93rPBk +new== X-Received: by 10.194.7.106 with SMTP id i10mr26845020wja.86.1441285000538; Thu, 03 Sep 2015 05:56:40 -0700 (PDT) Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id fz5sm8894524wic.18.2015.09.03.05.56.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Sep 2015 05:56:39 -0700 (PDT) References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> From: Dmitry Gutov Message-ID: <55E84382.3030209@yandex.ru> Date: Thu, 3 Sep 2015 15:56:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 09/03/2015 01:44 AM, Jonathan H wrote: > I'm using (vc-working-revision buffer-file-name (vc-responsible-backend > buffer-file-name)) to determine the current working revision. > > As far as I can tell, vc-working-revision will cache the current working > revision in a file property, but it doesn't know when to invalidate the > cache, so the results can be stale. Yes, invalidation of those properties could use some improvement. But if you're just worried about up-to-date results returned to your functions, you could remove the property before calling `vc-working-revision'. > In fact, in the specific case of > git, you probably can't get any faster than a rev-parse anyway, I wonder if that's true. Caching in a property is obviously fast, and process calls are necessarily an order of magnitude slower (and slower still on certain platforms). Maybe you should write a patch and test it on Windows (or have someone else do it), and see whether the mode-line updates don't become perceptibly slower. > I have a sneaking suspicion that git isn't the only backend where this > can happen. Probably. On the other hand, there are known backends where calling the backend program *is* slow. Such as Bazaar or (most likely) CVS. From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Sep 2015 16:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144129628020846 (code D ref 21383); Thu, 03 Sep 2015 16:05:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 3 Sep 2015 16:04:40 +0000 Received: from localhost ([127.0.0.1]:47819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXX0C-0005Q8-Er for submit@debbugs.gnu.org; Thu, 03 Sep 2015 12:04:40 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:43363) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXX09-0005Pz-Q1 for 21383-done@debbugs.gnu.org; Thu, 03 Sep 2015 12:04:38 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t83G4ZwF010505; Thu, 3 Sep 2015 12:04:36 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 0EC5466110; Thu, 3 Sep 2015 12:04:35 -0400 (EDT) From: Stefan Monnier Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> Date: Thu, 03 Sep 2015 12:04:35 -0400 In-Reply-To: <55E6D426.10105@yandex.ru> (Dmitry Gutov's message of "Wed, 2 Sep 2015 13:49:10 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5418=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5418> : inlines <3752> : streams <1499229> : uri <2031713> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > Yes. But as long as its only limited to the backends (and can be fixed > there), as opposed to being inherently present in vc.el, log-edit.el, etc, > it's less of a problem. I think the problem is in the contract between VC itself and the backends, because VC mostly assumes that default-directory doesn't matter and uses absolute file names instead (that was the original design), whereas for many backends this is sometimes inconvenient so they occasionally rely on default-directory instead, which happens to work as well, tho it's mostly an accident. > vc-file-setprop won't work on a relative path. Or shouldn't, at least. Clearly, what I suggest would require changes in the core VC code, yes. > And are you talking about FILE arg to vc-status, or e.g. vc-git-status? vc-git-status (and other backend operations). > And vc-git-working-revision won't care if FILE is absolute or relative, > which is the crux of the problem. I'd rather backends like Git, if we're > going to fix this, used FILE's parent directory to change default-directory > temporarily before calling Git. Right, we could fix the problem by keeping the original design and making sure the backends actually follow it, but I'm not sure it's the better design nowadays (and since using default-directory happens to work in 99% of the cases, it's hard to make sure we really fix all cases where we incorrectly rely on default-directory being the right parent of the absolute file names we get). Stefan From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Sep 2015 16:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144129702422409 (code D ref 21383); Thu, 03 Sep 2015 16:18:01 +0000 Received: (at 21383-done) by debbugs.gnu.org; 3 Sep 2015 16:17:04 +0000 Received: from localhost ([127.0.0.1]:47831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXXCB-0005pM-Q7 for submit@debbugs.gnu.org; Thu, 03 Sep 2015 12:17:04 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:58057) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXXCA-0005pD-H7 for 21383-done@debbugs.gnu.org; Thu, 03 Sep 2015 12:17:02 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t83GH1TU013590; Thu, 3 Sep 2015 12:17:01 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 6BCF666110; Thu, 3 Sep 2015 12:17:01 -0400 (EDT) From: Stefan Monnier Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E84382.3030209@yandex.ru> Date: Thu, 03 Sep 2015 12:17:01 -0400 In-Reply-To: <55E84382.3030209@yandex.ru> (Dmitry Gutov's message of "Thu, 3 Sep 2015 15:56:34 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered GEN_SPAM_FEATRE=0.2, RV5418=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5418> : inlines <3752> : streams <1499234> : uri <2031719> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > Maybe you should write a patch and test it on Windows (or have someone else > do it), and see whether the mode-line updates don't become > perceptibly slower. Indeed, mode-line updates are *very* frequent (more than once per command), so we really want to avoid running processes at that point. Stefan From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Jonathan H Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Sep 2015 17:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 21383-done@debbugs.gnu.org, Dmitry Gutov Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144130168030628 (code D ref 21383); Thu, 03 Sep 2015 17:35:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 3 Sep 2015 17:34:40 +0000 Received: from localhost ([127.0.0.1]:47863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXYPI-0007xv-Dg for submit@debbugs.gnu.org; Thu, 03 Sep 2015 13:34:40 -0400 Received: from mail-io0-f176.google.com ([209.85.223.176]:33618) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXYPG-0007xn-AK for 21383-done@debbugs.gnu.org; Thu, 03 Sep 2015 13:34:38 -0400 Received: by iofh134 with SMTP id h134so66899022iof.0 for <21383-done@debbugs.gnu.org>; Thu, 03 Sep 2015 10:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3idjm+gcxG22fXhcakc4dX6KJkYvxBWAfGb4E/KGDj0=; b=LjSvINIf8MM6AJMBVnejwOL0Z+ShKwX6R3EpKVofMgIkvtCo6QA1+ZY8chsiRGKwVk qrALf71IQIxG/IL93MkxYzW+Hs5Z/NY+5PglWePpFl4LPcRyT9Lgu2rBrylsTiwGWV/7 CS2iHr1P1vRNHU0tazSA745TMqPrO1FK9117sdVZaTKUHWEi8/gblMEz8apxXije3ArY hqSDHvsZpboYNK1UXfBJ+xaqlMuvT2h69G9ZiTn4X1EH1FzPWoenQFqH7lvbEh9tv/nW HZfcecMdy4Df7rak4hq3IGEB5SjpbQhoC3J4ffN+q2FBuBr4gZdboZr3h4OlmwgBh8oZ xjGA== X-Received: by 10.107.13.3 with SMTP id 3mr493364ion.70.1441301677574; Thu, 03 Sep 2015 10:34:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.110.197 with HTTP; Thu, 3 Sep 2015 10:34:08 -0700 (PDT) In-Reply-To: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E84382.3030209@yandex.ru> From: Jonathan H Date: Thu, 3 Sep 2015 10:34:08 -0700 Message-ID: Content-Type: multipart/alternative; boundary=001a113fd722819dde051edb324a X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a113fd722819dde051edb324a Content-Type: text/plain; charset=UTF-8 > Indeed, mode-line updates are *very* frequent (more than once per > command), so we really want to avoid running processes at that point. I though the new implementation of the vc-git mode line doesn't use vc-working-revision, so in this specific case, making vc-working-revision slower won't hurt us there. > I wonder if that's true. Caching in a property is obviously fast, and process calls are necessarily an order of magnitude slower (and slower still on certain platforms). True, but you have to check that the cache is invalid somehow. If you want to be super correct, a rev-parse is probably the fastest way. I suppose it would be pretty fast to check the mtime of the .git directory inside emacs and invalidate that when it changes. Although filesystem timestamps usually make me nervous, it's probably okay in this instance? On Thu, Sep 3, 2015 at 9:17 AM, Stefan Monnier wrote: > > Maybe you should write a patch and test it on Windows (or have someone > else > > do it), and see whether the mode-line updates don't become > > perceptibly slower. > > Indeed, mode-line updates are *very* frequent (more than once per > command), so we really want to avoid running processes at that point. > > > Stefan > --001a113fd722819dde051edb324a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Indeed, mode-line updates are *very* f= requent (more than once per
> command), so we really want to avoid running processes at that point.<= br>
I though the new implementation of the vc-git mode line doesn&= #39;t use vc-working-revision, so in this specific case, making vc-working-= revision slower won't hurt us there.

> I wonder if that's= true. Caching in a property is obviously fast, and=20 process calls are
necessarily an order of magnitude slower (and slower= =20 still on certain platforms).

True, but you have to check that = the cache is invalid somehow. If you want to be super correct, a rev-parse = is probably the fastest way. I suppose it would be pretty fast to check the= mtime of the .git directory inside emacs and invalidate that when it chang= es. Although filesystem timestamps usually make me nervous, it's probab= ly okay in this instance?



On Th= u, Sep 3, 2015 at 9:17 AM, Stefan Monnier <monnier@iro.umontreal.ca= > wrote:
&= gt; Maybe you should write a patch and test it on Windows (or have someone = else
> do it), and see whether the mode-line updates don't become
> perceptibly slower.

Indeed, mode-line updates are *very* frequent (more than once per command), so we really want to avoid running processes at that point.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan

--001a113fd722819dde051edb324a-- From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Sep 2015 18:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jonathan H , Stefan Monnier Cc: 21383-done@debbugs.gnu.org Received: via spool by 21383-done@debbugs.gnu.org id=D21383.14413056644537 (code D ref 21383); Thu, 03 Sep 2015 18:42:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 3 Sep 2015 18:41:04 +0000 Received: from localhost ([127.0.0.1]:47906 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXZRX-0001B7-L4 for submit@debbugs.gnu.org; Thu, 03 Sep 2015 14:41:03 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:38788) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXZRV-0001Ab-KV for 21383-done@debbugs.gnu.org; Thu, 03 Sep 2015 14:41:02 -0400 Received: by wiclk2 with SMTP id lk2so17664943wic.1 for <21383-done@debbugs.gnu.org>; Thu, 03 Sep 2015 11:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=GiD/DYxjIZYZJ3D3mQTf0KeIBiRBU90WnrL1gD7VEq8=; b=b/r5XtlGfBt4/sR2BBxRL1YNCYU+aGEjLlZMX+rFrqEkSIXXYPozz+WuA2EYW6srMA Bz040iNd2Axs1Jb4a/sGqYJY292L7w/sqq/eqIcuOKsA04HtPD8CcjNsAfU0c6eJiZ99 3RImWvBGmSJQy/CKwGDf4tJWNJksAtpv4XXxyEoxi4wYTVyi6cJoeXsVxWhQkraDxbrA dILWXyHFGcAZYvHEtgD8XpItoCy/oZmtxcKB0Xrn27/D0gVsJVB8OX3Mp7wWdLs2a9kq 8Mdfbe5EfBaJgSZpCeudX0dEybZDaOJ/lpanBVvYllsUGXTCW6TKFu2Bmcb5j1avYk0f 2U6w== X-Received: by 10.180.240.172 with SMTP id wb12mr17155519wic.64.1441305661002; Thu, 03 Sep 2015 11:41:01 -0700 (PDT) Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id m4sm39021146wjb.37.2015.09.03.11.40.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Sep 2015 11:41:00 -0700 (PDT) References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E84382.3030209@yandex.ru> From: Dmitry Gutov Message-ID: <55E89436.7050603@yandex.ru> Date: Thu, 3 Sep 2015 21:40:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 09/03/2015 08:34 PM, Jonathan H wrote: > I though the new implementation of the vc-git mode line doesn't use > vc-working-revision, Please look at the definition. vc-working-revision is called once in the beginning of the function, and again through vc-default-mode-line-string. Even if we inlined the useful parts of vc-default-mode-line-string definition, calling vc-git-working-revision instead of vc-git--symbolic-ref is still inevitable in "detached" [Git] mode. > True, but you have to check that the cache is invalid somehow. If you > want to be super correct, a rev-parse is probably the fastest way. I We err on the side of speed currently, instead of correctness. The file properties are invalidated during certain operations, like saving or reverting the buffer. > suppose it would be pretty fast to check the mtime of the .git directory > inside emacs and invalidate that when it changes. Although filesystem > timestamps usually make me nervous, it's probably okay in this instance? I don't know, but it's probably not too hard to imagine a user with a terminally slow HDD. Maybe it'll be fast enough anyway, but someone will have to do a patch, and test. From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Sep 2015 19:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.14413083038549 (code D ref 21383); Thu, 03 Sep 2015 19:26:01 +0000 Received: (at 21383-done) by debbugs.gnu.org; 3 Sep 2015 19:25:03 +0000 Received: from localhost ([127.0.0.1]:47924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXa86-0002Dp-BB for submit@debbugs.gnu.org; Thu, 03 Sep 2015 15:25:02 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:34312) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXa83-0002DM-NZ for 21383-done@debbugs.gnu.org; Thu, 03 Sep 2015 15:25:00 -0400 Received: by wicfx3 with SMTP id fx3so786283wic.1 for <21383-done@debbugs.gnu.org>; Thu, 03 Sep 2015 12:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Z2TeXcIsPzD3Wcj4N6QdSZKwetim398NGC0IbV5Pxxs=; b=dR2PQiXugv2e/KbvEbaKgT8iX7R6V7ctkHtarlh8S0SiwifF6nDLeWPv1mcTI9z0fY OVIivx7417gpPwFNfNmdkYiJKPBjVdkRk/uYkSHLZhmiLocTEolPX3STYiEtiBoJMLXg zqMngHXQyme5GLo3V5abE/s3JepU02H6/+H01dynEHesKvozn2ddhakszf7bzEVQsyLX 0Lp3DkUOGxdgs2dHx0G5msNhBMNUWhH7XR/UvPj705PHWs4RS0TGeO4gpPkCmSQr7WJ0 XudYmrtgv4dmtwpjO08xlbglmIj5xtH69t95/GvJmaBSHtiNBIiKa85nEVefz4upJ6jD jHDA== X-Received: by 10.180.106.66 with SMTP id gs2mr17594128wib.14.1441308299033; Thu, 03 Sep 2015 12:24:59 -0700 (PDT) Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id ik8sm39251083wjb.8.2015.09.03.12.24.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Sep 2015 12:24:57 -0700 (PDT) References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> From: Dmitry Gutov Message-ID: <55E89E83.6000501@yandex.ru> Date: Thu, 3 Sep 2015 22:24:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 09/03/2015 07:04 PM, Stefan Monnier wrote: > I think the problem is in the contract between VC itself and the > backends, because VC mostly assumes that default-directory doesn't > matter and uses absolute file names instead (that was the original > design), whereas for many backends this is sometimes inconvenient so > they occasionally rely on default-directory instead, which happens to > work as well, tho it's mostly an accident. Yes. >> And are you talking about FILE arg to vc-status, or e.g. vc-git-status? > > vc-git-status (and other backend operations). That might be viable. But the commands that don't use FILE currently only need the root, so we could avoid passing the argument in entirely. > Right, we could fix the problem by keeping the original design and > making sure the backends actually follow it, but I'm not sure it's the > better design nowadays (and since using default-directory happens to > work in 99% of the cases, it's hard to make sure we really fix all cases > where we incorrectly rely on default-directory being the right parent of > the absolute file names we get). That is true. But could we abandon the current design for all backends? Some of the older ones still don't have vc-root implemented (because it's impossible for some of them?), and until it is, vc-state and friends won't know what to set default-directory to. From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Sep 2015 20:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144131085418848 (code D ref 21383); Thu, 03 Sep 2015 20:08:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 3 Sep 2015 20:07:34 +0000 Received: from localhost ([127.0.0.1]:47960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXanG-0004tw-FK for submit@debbugs.gnu.org; Thu, 03 Sep 2015 16:07:34 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:42036) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXanF-0004tn-8P for 21383-done@debbugs.gnu.org; Thu, 03 Sep 2015 16:07:33 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t83K7W8f009947; Thu, 3 Sep 2015 16:07:32 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 137F366110; Thu, 3 Sep 2015 16:07:32 -0400 (EDT) From: Stefan Monnier Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E84382.3030209@yandex.ru> <55E89436.7050603@yandex.ru> Date: Thu, 03 Sep 2015 16:07:32 -0400 In-Reply-To: <55E89436.7050603@yandex.ru> (Dmitry Gutov's message of "Thu, 3 Sep 2015 21:40:54 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5418=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5418> : inlines <3754> : streams <1499319> : uri <2031850> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > We err on the side of speed currently, instead of correctness. The file > properties are invalidated during certain operations, like saving or > reverting the buffer. Also VC was designed when revisions were per-file, and the way we extended it is to say that it's OK to have an out-of-date revision number for a given file, if that file's content is the same in the current revision. Stefan From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Sep 2015 22:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.14413195456260 (code D ref 21383); Thu, 03 Sep 2015 22:33:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 3 Sep 2015 22:32:25 +0000 Received: from localhost ([127.0.0.1]:48004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXd3Q-0001ct-B1 for submit@debbugs.gnu.org; Thu, 03 Sep 2015 18:32:24 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:37013) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXd3N-0001ce-SJ for 21383-done@debbugs.gnu.org; Thu, 03 Sep 2015 18:32:22 -0400 Received: by wicfx3 with SMTP id fx3so114985wic.0 for <21383-done@debbugs.gnu.org>; Thu, 03 Sep 2015 15:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=SwAkBamTouePvkr+E4VTriKzREnV2ddA6s28zdHlZC0=; b=sygLGAUaE4cdYmmfTF79T+lHmTnyeF150sILDVi2g5AtUd08L9AK7uKLkiXlcScYYc mWdr/YcKk9lfMPNinxoinefn7Ws9Tt1XXjOWtptqxoY6QYQkaL8a+5ptVrqoFR1Yh+V6 sODcYYBoOIEj6rcuTXQHyYl0ABbIwoaYGYFR4kX/JporXPrj1ozCstPlQbz1nDrYWFqD YR8/fiGO8zFRnpRUBiAbJVkKMrsoMZeY54j9SiSX7v/IsZNzuLqxBAKzHTc6IZZZj3Je avPRm++SiuuKgJ73fBAaw1dS+Iu7XTj6iz6UBlM+aBXNE47Yt2RvdH5e4DEaIAs5fkMp s8tQ== X-Received: by 10.181.25.234 with SMTP id it10mr982942wid.41.1441319541274; Thu, 03 Sep 2015 15:32:21 -0700 (PDT) Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id i7sm510775wib.15.2015.09.03.15.32.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Sep 2015 15:32:20 -0700 (PDT) References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E84382.3030209@yandex.ru> <55E89436.7050603@yandex.ru> From: Dmitry Gutov Message-ID: <55E8CA6E.6070002@yandex.ru> Date: Fri, 4 Sep 2015 01:32:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 09/03/2015 11:07 PM, Stefan Monnier wrote: > Also VC was designed when revisions were per-file, and the way we > extended it is to say that it's OK to have an out-of-date revision > number for a given file, if that file's content is the same in the > current revision. This might be one of the more annoying discrepancies, and one that's not too hard to improve. I wonder if I've missed any other good places to reset the root's properties. diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el index ec55867..a27c873 100644 --- a/lisp/vc/vc-dispatcher.el +++ b/lisp/vc/vc-dispatcher.el @@ -567,7 +567,10 @@ editing!" (if (string= buffer-file-name file) (vc-resynch-window file keep noquery reset-vc-info) (if (file-directory-p file) - (vc-resynch-buffers-in-directory file keep noquery reset-vc-info) + (progn + (when reset-vc-info + (vc-file-clearprops file)) + (vc-resynch-buffers-in-directory file keep noquery reset-vc-info)) (let ((buffer (get-file-buffer file))) (when buffer (with-current-buffer buffer diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el index 8a0f554..33d742c 100644 --- a/lisp/vc/vc-git.el +++ b/lisp/vc/vc-git.el @@ -254,15 +254,16 @@ matching the resulting Git log output, and KEYWORDS is a list of (vc-git--rev-parse "HEAD"))) (defun vc-git--symbolic-ref (file) - (or - (vc-file-getprop file 'vc-git-symbolic-ref) - (let* (process-file-side-effects - (str (vc-git--run-command-string nil "symbolic-ref" "HEAD"))) - (vc-file-setprop file 'vc-git-symbolic-ref - (if str - (if (string-match "^\\(refs/heads/\\)?\\(.+\\)$" str) - (match-string 2 str) - str)))))) + (let ((root (vc-git-root file))) + (or + (vc-file-getprop root 'vc-git-symbolic-ref) + (let* (process-file-side-effects + (str (vc-git--run-command-string nil "symbolic-ref" "HEAD"))) + (vc-file-setprop root 'vc-git-symbolic-ref + (if str + (if (string-match "^\\(refs/heads/\\)?\\(.+\\)$" str) + (match-string 2 str) + str))))))) (defun vc-git-mode-line-string (file) "Return a string for `vc-mode-line' to put in the mode line for FILE." diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el index e674f0e..4bee8ad 100644 --- a/lisp/vc/vc-hooks.el +++ b/lisp/vc/vc-hooks.el @@ -493,12 +493,15 @@ status of this file. Otherwise, the value returned is one of: (defun vc-working-revision (file &optional backend) "Return the repository version from which FILE was checked out. If FILE is not registered, this function always returns nil." - (or (vc-file-getprop file 'vc-working-revision) - (progn - (setq backend (or backend (vc-responsible-backend file))) - (when backend - (vc-file-setprop file 'vc-working-revision - (vc-call-backend backend 'working-revision file)))))) + (unless backend (setq backend (vc-responsible-backend file))) + (when backend + (let* ((granularity (vc-call-backend backend 'revision-granularity)) + (prop-target (if (eq granularity 'repository) + (vc-call-backend backend 'root file) + file))) + (or (vc-file-getprop prop-target 'vc-working-revision) + (vc-file-setprop prop-target 'vc-working-revision + (vc-call-backend backend 'working-revision file)))))) ;; Backward compatibility. (define-obsolete-function-alias From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Sep 2015 02:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144133326110197 (code D ref 21383); Fri, 04 Sep 2015 02:22:01 +0000 Received: (at 21383-done) by debbugs.gnu.org; 4 Sep 2015 02:21:01 +0000 Received: from localhost ([127.0.0.1]:48321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXgce-0002e8-V4 for submit@debbugs.gnu.org; Thu, 03 Sep 2015 22:21:01 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:49378) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXgcb-0002dx-Lh for 21383-done@debbugs.gnu.org; Thu, 03 Sep 2015 22:20:58 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AyFgA731xV//rn92hcgxCEAoVVu0CHSwQCAoE8OxIBAQEBAQEBgQpBBYNdAQEDAVYjBQsLDiYSFBgNJIg3CM8jAQEBAQYBAQEBHos6hQUHhC0Fi0SpQCOEFCKCeAEBAQ X-IPAS-Result: A0AyFgA731xV//rn92hcgxCEAoVVu0CHSwQCAoE8OxIBAQEBAQEBgQpBBYNdAQEDAVYjBQsLDiYSFBgNJIg3CM8jAQEBAQYBAQEBHos6hQUHhC0Fi0SpQCOEFCKCeAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="162359203" Received: from 104-247-231-250.cpe.teksavvy.com (HELO ceviche.home) ([104.247.231.250]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Sep 2015 22:20:56 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 9654066096; Thu, 3 Sep 2015 22:20:56 -0400 (EDT) From: Stefan Monnier Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E89E83.6000501@yandex.ru> Date: Thu, 03 Sep 2015 22:20:56 -0400 In-Reply-To: <55E89E83.6000501@yandex.ru> (Dmitry Gutov's message of "Thu, 3 Sep 2015 22:24:51 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > That might be viable. But the commands that don't use FILE currently only > need the root, so we could avoid passing the argument in entirely. IIUC those operations are things like `working-revision', which should return values which may depend on the FILE or not, depending on the semantics of the backend. So I don't think we can drop the FILE argument, but we can make it clear that it's OK to ignore it and use default-directory instead. That's why I'm suggesting to pass FILE as a relative file-name. It is slightly delicate, tho, since the vc-root for default-directory may actually be different from the vc-root for (expand-file-name ). > That is true. But could we abandon the current design for all backends? Some > of the older ones still don't have vc-root implemented (because it's > impossible for some of them?), and until it is, vc-state and friends won't > know what to set default-directory to. I don't think we should impose a constraint that default-directory is vc-root. So, backends like Git may still have to find the vc-root from the default-directory (tho in many cases, the underlying executable will do that for us). Stefan From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Sep 2015 14:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144137740328716 (code D ref 21383); Fri, 04 Sep 2015 14:37:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 4 Sep 2015 14:36:43 +0000 Received: from localhost ([127.0.0.1]:48909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXs6c-0007T6-H3 for submit@debbugs.gnu.org; Fri, 04 Sep 2015 10:36:42 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:39737) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXs6a-0007Sw-Cn for 21383-done@debbugs.gnu.org; Fri, 04 Sep 2015 10:36:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A+FgA731xV/1SBWxdcgxCEAoVVwwsEAgKBPD0QAQEBAQEBAYEKQQWDXQEBAwFWIxALDiYSFBgNJIg3CM8jAQEBAQYBAQEBHos6hQUHhC0FtQQjhBQigngBAQE X-IPAS-Result: A0A+FgA731xV/1SBWxdcgxCEAoVVwwsEAgKBPD0QAQEBAQEBAYEKQQWDXQEBAwFWIxALDiYSFBgNJIg3CM8jAQEBAQYBAQEBHos6hQUHhC0FtQQjhBQigngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="162414602" Received: from 23-91-129-84.cpe.pppoe.ca (HELO ceviche.home) ([23.91.129.84]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Sep 2015 10:36:39 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 5449F66092; Fri, 4 Sep 2015 10:36:39 -0400 (EDT) From: Stefan Monnier Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E84382.3030209@yandex.ru> <55E89436.7050603@yandex.ru> <55E8CA6E.6070002@yandex.ru> Date: Fri, 04 Sep 2015 10:36:39 -0400 In-Reply-To: <55E8CA6E.6070002@yandex.ru> (Dmitry Gutov's message of "Fri, 4 Sep 2015 01:32:14 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> Also VC was designed when revisions were per-file, and the way we >> extended it is to say that it's OK to have an out-of-date revision >> number for a given file, if that file's content is the same in the >> current revision. > This might be one of the more annoying discrepancies, Why? In which kinds of circumstances can this bite us? Stefan From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Sep 2015 02:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144142023411195 (code D ref 21383); Sat, 05 Sep 2015 02:31:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 5 Sep 2015 02:30:34 +0000 Received: from localhost ([127.0.0.1]:49140 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZY3FR-0002uV-HX for submit@debbugs.gnu.org; Fri, 04 Sep 2015 22:30:33 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:37244) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZY3FO-0002uK-9O for 21383-done@debbugs.gnu.org; Fri, 04 Sep 2015 22:30:30 -0400 Received: by wicfx3 with SMTP id fx3so33453535wic.0 for <21383-done@debbugs.gnu.org>; Fri, 04 Sep 2015 19:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=uQcBMdjxthU5trKap6KpyefTBGIlooBoP3aZF/yKEs4=; b=fgfN6qdwnmLLRNCU9puWOT0e+45eU9DWBf8FcNCpL16/EtnMdloCWHX28dvQZQqCCb Di67JoBeqp/8ZDohYgDWd7hiHj6fsAzpJpqdZqB7oAK7pT61BiR7UpSoeHFB6xLBaRZa 1/R2TQMmMqC3QpPrsIwURdVsHtcgIoFFtVFSpGmbdUyRmXuIvPFUW3KY0csTz+ZqWBi7 RWiLOHbjAgLGoo6QybZFaKpSLAAy9S9iZHQd0W0A2A/IwTpItJIQD1ydj7bCHVrU4pcO I0QtUyRhVFx/4qEGuYB/Hp6RiCALcv2vK13skbH9ZbCGPI89aCn/GP+4kw9mjNcUrC/a YWFg== X-Received: by 10.180.99.5 with SMTP id em5mr12899829wib.43.1441420229668; Fri, 04 Sep 2015 19:30:29 -0700 (PDT) Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id en5sm7389822wib.18.2015.09.04.19.30.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Sep 2015 19:30:28 -0700 (PDT) References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E84382.3030209@yandex.ru> <55E89436.7050603@yandex.ru> <55E8CA6E.6070002@yandex.ru> From: Dmitry Gutov Message-ID: <55EA53C2.6060001@yandex.ru> Date: Sat, 5 Sep 2015 05:30:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 09/04/2015 05:36 PM, Stefan Monnier wrote: > Why? In which kinds of circumstances can this bite us? It goes somewhere like this: I switch to a different branch (using the console), some buffers see that they're out of date and get reverted automatically (and/or I `M-x revert-buffer' in some buffer), and then some buffers from a project show one branch in their mode-line, and other buffers show a different branch. That can be annoying and makes me question which branch is actually checked out. (Note that the patch I've posted now makes M-x revert-buffer never update the current branch; that's a very consistent behavior :)). From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Sep 2015 03:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144142251914613 (code D ref 21383); Sat, 05 Sep 2015 03:09:01 +0000 Received: (at 21383-done) by debbugs.gnu.org; 5 Sep 2015 03:08:39 +0000 Received: from localhost ([127.0.0.1]:49167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZY3qI-0003nc-Bs for submit@debbugs.gnu.org; Fri, 04 Sep 2015 23:08:38 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:34293) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZY3qG-0003nU-DH for 21383-done@debbugs.gnu.org; Fri, 04 Sep 2015 23:08:36 -0400 Received: by wicfx3 with SMTP id fx3so38532962wic.1 for <21383-done@debbugs.gnu.org>; Fri, 04 Sep 2015 20:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=DwJaZGqgUqvN9AjQu2fAIqeEaK7KnVIxVEfBmiiyrf8=; b=musM3/FJpMhShfoo4c14Kkyc7n45MjrF1PVr7H6EU+52704aNkylh0tZLgyghSPrei uo7nr8ydpevqI+/N+2e0demXNjHtmNiuNM8QrUYWF4dHZYeUJvtypZyTM1PgzU7HqqtL AsGP3RPfWodZekHY6/aNly1u+Baa+wJ+STZ4cum9lrtuiO6xJwxenOXDcoaAMz+BHNoF 8TbgHjNNetlVBn3WmFwVBpLrFkTb6kG+HS8uciPHwWiZU+s1I/pwwA4BD21RydiRMTu5 QuXZR23uv6XDBNfInsLCXrnE+4/T5U0wiqfljJhs2+4/nCPptjUcDErQ028xKN6fn9UV SzAA== X-Received: by 10.180.10.8 with SMTP id e8mr12763967wib.22.1441422515867; Fri, 04 Sep 2015 20:08:35 -0700 (PDT) Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id du6sm7694685wib.24.2015.09.04.20.08.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Sep 2015 20:08:34 -0700 (PDT) References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E89E83.6000501@yandex.ru> From: Dmitry Gutov Message-ID: <55EA5CB0.9070007@yandex.ru> Date: Sat, 5 Sep 2015 06:08:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 09/04/2015 05:20 AM, Stefan Monnier wrote: > So I don't think we can drop the FILE argument, but we can make it > clear that it's OK to ignore it and use default-directory instead. That, by itself, would be an easy change to make. In the docs. > That's why I'm suggesting to pass FILE as a relative file-name. > It is slightly delicate, tho, since the vc-root for default-directory > may actually be different from the vc-root for (expand-file-name > ). My problem with that is passing a relative file-name doesn't help any backend, in any way: if the file-name is relative to the current default-directory, vc-git-* will continue behaving exactly the same, whether default-directory is the root, or simply the current directory. If the file-name is relative to some other directory that the current (from vc-git's standpoint) default-directory, then vc-git operations will simply fail. Either way, the onus is on vc-working-revision and other generic functions to bind default-directory. And as long as default-directory is right, the file-names might as well stay absolute. > I don't think we should impose a constraint that default-directory is > vc-root. So, backends like Git may still have to find the vc-root > from the default-directory (tho in many cases, the underlying executable > will do that for us). If default-directory is outside of $git_repo, passing a path to a file inside it to 'git status' doesn't work. So someone still needs to bind default-directory to somewhere inside it. However - this looks like the easiest solution - binding it to (file-name-directory file) should work well enough for backends with either type of revision granularity. At least as long as the backend program can be called in any subdirectory of the repository. From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Sep 2015 15:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.14414659827096 (code D ref 21383); Sat, 05 Sep 2015 15:14:02 +0000 Received: (at 21383-done) by debbugs.gnu.org; 5 Sep 2015 15:13:02 +0000 Received: from localhost ([127.0.0.1]:50048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYF9K-0001qG-2n for submit@debbugs.gnu.org; Sat, 05 Sep 2015 11:13:02 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:64746) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYF9H-0001q0-Hz for 21383-done@debbugs.gnu.org; Sat, 05 Sep 2015 11:13:00 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AyFgA731xV/xGkpUVcgxCEAoVVu0CHSwQCAoE8OhMBAQEBAQEBgQpBBYNdAQEDAVYjBQsLDiYSFBgNJIg3CM8jAQEBAQYBAQEBHos6hQUHhC0Fi0Sne4FFI4QUIoJ4AQEB X-IPAS-Result: A0AyFgA731xV/xGkpUVcgxCEAoVVu0CHSwQCAoE8OhMBAQEBAQEBgQpBBYNdAQEDAVYjBQsLDiYSFBgNJIg3CM8jAQEBAQYBAQEBHos6hQUHhC0Fi0Sne4FFI4QUIoJ4AQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="162563915" Received: from 69-165-164-17.dsl.teksavvy.com (HELO ceviche.home) ([69.165.164.17]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Sep 2015 11:12:58 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 4A7B466482; Sat, 5 Sep 2015 11:12:58 -0400 (EDT) From: Stefan Monnier Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E89E83.6000501@yandex.ru> <55EA5CB0.9070007@yandex.ru> Date: Sat, 05 Sep 2015 11:12:58 -0400 In-Reply-To: <55EA5CB0.9070007@yandex.ru> (Dmitry Gutov's message of "Sat, 5 Sep 2015 06:08:32 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> That's why I'm suggesting to pass FILE as a relative file-name. >> It is slightly delicate, tho, since the vc-root for default-directory >> may actually be different from the vc-root for (expand-file-name >> ). > My problem with that is passing a relative file-name doesn't help any > backend, in any way: if the file-name is relative to the current > default-directory, [ By and large, a file name that's not relative to default-directory is a dead file name. ] Yes, the file names would be relative to default-directory. > functions to bind default-directory. And as long as default-directory is > right, the file-names might as well stay absolute. But that means we pass redundant info, and that's only acceptable if we can make reasonably sure that the two copies are in sync. Using relative file names we don't have the problem of keeping duplicate info in sync. >> I don't think we should impose a constraint that default-directory is >> vc-root. So, backends like Git may still have to find the vc-root >> from the default-directory (tho in many cases, the underlying executable >> will do that for us). > If default-directory is outside of $git_repo, passing a path to a file > inside it to 'git status' doesn't work. So someone still needs to bind > default-directory to somewhere inside it. No, I think that it's perfectly acceptable to say that the Git branch used depends solely on default-directory. So if default-directory is outside of $git_repo, you get what you asked for. Stefan From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Sep 2015 20:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.14414850253399 (code D ref 21383); Sat, 05 Sep 2015 20:31:01 +0000 Received: (at 21383-done) by debbugs.gnu.org; 5 Sep 2015 20:30:25 +0000 Received: from localhost ([127.0.0.1]:50097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYK6T-0000sk-0X for submit@debbugs.gnu.org; Sat, 05 Sep 2015 16:30:25 -0400 Received: from mail-lb0-f179.google.com ([209.85.217.179]:36513) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYK6Q-0000sX-8D for 21383-done@debbugs.gnu.org; Sat, 05 Sep 2015 16:30:23 -0400 Received: by lbcao8 with SMTP id ao8so25314412lbc.3 for <21383-done@debbugs.gnu.org>; Sat, 05 Sep 2015 13:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=w2UMKJQX1KbHmF6RHyEB4GUJCIa/E4NaO5IJL/6Eufg=; b=K3loN31BJ2IiIYRW2Eifmldxt3dWF2peb5RnIY9mWMy6lZY1qktrCEEtDQOhWdgI9c 0yICWS80N9trZvNuw8rL2y7vWngu5ehTK3AdTqX2091X4Y1EeokSvlCIvyw/RboF5Q3k x6wie8HYjt4hG6k4V7VOJ7AVsaxJ0Zu+FIVsRC5AmdAFzCorBSKFQVPvr6YEEdCOW3z7 4seDPTgSpqgM9nDflVzUxf6tHNGkm8wB3MxasW1deRP/VBbNMj8LlWog+oXlkVn0v/rt FWw9Db9wwUq4FEJk9VEoQt0tjFTxuHF34MYxZwN1lLF5YDbN8JAcKL0aW1Z6lRvS7ylj u7xw== X-Received: by 10.112.189.161 with SMTP id gj1mr9911605lbc.20.1441485021244; Sat, 05 Sep 2015 13:30:21 -0700 (PDT) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id si3sm1651320lbb.32.2015.09.05.13.30.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Sep 2015 13:30:20 -0700 (PDT) References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E89E83.6000501@yandex.ru> <55EA5CB0.9070007@yandex.ru> From: Dmitry Gutov Message-ID: <55EB50D7.2030103@yandex.ru> Date: Sat, 5 Sep 2015 23:30:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 09/05/2015 06:12 PM, Stefan Monnier wrote: > Yes, the file names would be relative to default-directory. Does vc-status get a relative file name as input? If yes, a) it's additional work for the caller, b) how are you going to enforce it?. Otherwise, (*). > But that means we pass redundant info, and that's only acceptable if we > can make reasonably sure that the two copies are in sync. > Using relative file names we don't have the problem of keeping duplicate > info in sync. (*) If we try to eliminate this duplication of info, we introduce duplication of effort inside VC. Seems to be pointless complexity. > No, I think that it's perfectly acceptable to say that the Git branch > used depends solely on default-directory. So if default-directory is > outside of $git_repo, you get what you asked for. This is true, but I'm not sure what you're getting at. Sorry. From unknown Sun Jun 22 11:37:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#21383: Static revisions in vc-working-revision Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Sep 2015 22:30:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 21383-done@debbugs.gnu.org, Jonathan H Received: via spool by 21383-done@debbugs.gnu.org id=D21383.14415785695229 (code D ref 21383); Sun, 06 Sep 2015 22:30:04 +0000 Received: (at 21383-done) by debbugs.gnu.org; 6 Sep 2015 22:29:29 +0000 Received: from localhost ([127.0.0.1]:50982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYiRE-0001MH-Lo for submit@debbugs.gnu.org; Sun, 06 Sep 2015 18:29:28 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:35500) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYiRC-0001M9-W8 for 21383-done@debbugs.gnu.org; Sun, 06 Sep 2015 18:29:27 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AyFgA731xV/xGkpUVcgxCEAoVVu0CHSwQCAoE8OxIBAQEBAQEBgQpBBYNdAQEDAVYjBQsLDiYSFBgNJIg3CM8jAQEBAQYBAQEBAR2LOoUFB4QtAQSLRKd7gUUjhBQigngBAQE X-IPAS-Result: A0AyFgA731xV/xGkpUVcgxCEAoVVu0CHSwQCAoE8OxIBAQEBAQEBgQpBBYNdAQEDAVYjBQsLDiYSFBgNJIg3CM8jAQEBAQYBAQEBAR2LOoUFB4QtAQSLRKd7gUUjhBQigngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="162693575" Received: from 69-165-164-17.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.165.164.17]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Sep 2015 18:29:27 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 2AF44AE042; Sun, 6 Sep 2015 18:29:26 -0400 (EDT) From: Stefan Monnier Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E89E83.6000501@yandex.ru> <55EA5CB0.9070007@yandex.ru> <55EB50D7.2030103@yandex.ru> Date: Sun, 06 Sep 2015 18:29:26 -0400 In-Reply-To: <55EB50D7.2030103@yandex.ru> (Dmitry Gutov's message of "Sat, 5 Sep 2015 23:30:15 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> Yes, the file names would be relative to default-directory. > Does vc-status get a relative file name as input? Currently, I don't think so. But that could be changed if needed. > b) how are you going to enforce it?. By checking all callers? > (*) If we try to eliminate this duplication of info, we introduce > duplication of effort inside VC. Seems to be pointless complexity. Clearly it's easy to get back the absolute file name with just (expand-file-name ), and I don't see where we'd obviously get duplication of efforts. So I'm not sure why you think it'd add complexity. What I do see as a problem is that it would require a careful study&adjustment of the whole VC code. I'm not sure if the result would be more complex or simpler, admittedly. I think it'd be about the same, just with cleaner semantics. > This is true, but I'm not sure what you're getting at. Sorry. I guess I don't know either, I was just pointing out that the problem you point out can be defined away as a feature. Stefan