{"thread":{"id":"5860","subject":"Does GIT has vc keywords like CVS/Subversion?","startedAt":"2006-10-09T01:25:47Z","lastAt":"2006-10-10T17:41:13Z","messageCount":12,"participants":["Dongsheng Song","Liu Yubao","Petr Baudis","Linus Torvalds","Martin Langhoff","Johannes Schindelin","Junio C Hamano","Rene Scharfe","Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"28441","messageId":"4b3406f0610081825y1d066579yba305b6540c8d0e9@mail.gmail.com","threadId":"5860","inReplyTo":null,"subject":"Does GIT has vc keywords like CVS/Subversion?","fromName":"Dongsheng Song","fromEmail":"dongsheng.song@gmail.com","sentAt":"2006-10-09T01:25:47Z","receivedAt":"2006-10-09T01:25:47Z","isPatch":false,"sender":{"key":"dongsheng.song@gmail.com","avatar":null},"body":"I want to know whether there is a plan to add this feature, or GIT\ndoesn't require it at all.\n\nKeywords like LastChangedDate, LastChangedRevision, LastChangedBy, Id\nare useful for version control.\n\nDongsheng\n"},{"id":"28442","messageId":"4529B77A.707@gmail.com","threadId":"5860","inReplyTo":"4b3406f0610081825y1d066579yba305b6540c8d0e9@mail.gmail.com","subject":"Re: Does GIT has vc keywords like CVS/Subversion?","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-10-09T02:44:10Z","receivedAt":"2006-10-09T02:44:10Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Dongsheng Song wrote:\n> I want to know whether there is a plan to add this feature, or GIT\n> doesn't require it at all.\n> \n> Keywords like LastChangedDate, LastChangedRevision, LastChangedBy, Id\n> are useful for version control.\n> \nI almost mistake I sent my last question twice:-), maybe we need more FAQs\nlike this:\nQ: Does GIT [some feature] like [some vcs] ?\nA: No. Because ...\n\nIMHO, I don't think keyword substitution is a good idea, as it will confuse\nthe external diff/merge tools.\n"},{"id":"28444","messageId":"20061009025905.GM20017@pasky.or.cz","threadId":"5860","inReplyTo":"4529B77A.707@gmail.com","subject":"Re: Does GIT has vc keywords like CVS/Subversion?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-09T02:59:05Z","receivedAt":"2006-10-09T02:59:05Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Oct 09, 2006 at 04:44:10AM CEST, I got a letter\nwhere Liu Yubao said that...\n> Dongsheng Song wrote:\n> >I want to know whether there is a plan to add this feature, or GIT\n> >doesn't require it at all.\n> >\n> >Keywords like LastChangedDate, LastChangedRevision, LastChangedBy, Id\n> >are useful for version control.\n> >\n> I almost mistake I sent my last question twice:-), maybe we need more FAQs\n> like this:\n> Q: Does GIT [some feature] like [some vcs] ?\n> A: No. Because ...\n\nI have added direct link to FAQ in the Git wiki to the Git homepage\nheader - http://git.or.cz/gitwiki/GitFaq. It's a wiki, so feel free to\nadd more q/a there.\n\n> IMHO, I don't think keyword substitution is a good idea, as it will confuse\n> the external diff/merge tools.\n\nThere can be valid usage scenarios for keyword substitution but I tend\nto agree that it usually is not necessary to have it (and projects tend\nto use it just \"because we can\", which is of course their right). Also,\nimplementing it in Git poses some challenges and has some ugly\nimplications (like actually having to start to worry about binary\nfiles).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i \n> IMHO, I don't think keyword substitution is a good idea, as it will confuse\n> the external diff/merge tools.\n\nThere are other reasons why it's a _horrible_ idea, like the fact that it \ncan mess up binary files etc (so if you do keyword substitution, you also \nneed to suddenly care _deeply_ whether a file is binary or not).\n\nThe whole notion of keyword substitution is just totally idiotic. It's \ntrivial to do \"outside\" of the actual content tracking, if you want to \nhave it when doing release trees as tar-balls etc.\n\nSo:\n - inside of the SCM, keyword substitution is pointless, since you have \n much better tools available (like \"git log filename\")\n - outside of the SCM, keyword substitution can make sense, but doing it \n should be in helper scripts or something that can easily tailor it for \n the actual need of that particular project.\n\nFor example, we actually do a certain kind of keyword subtituion for the \nkernel. Look at the -git snapshots: the script that generates the snapshot \ndiffs has a simple sequence in it to \"keyword substitute\" the Makefile for \nthe EXTRAVERSION flag, so the diff will result in the Makefile having the \nknowledge of which git SHA1 version the resulting patch was, even though \nthe thing isn't a git tree any more:\n\n\t...\n\tgit-read-tree $CURCOMM\n\tgit-checkout-index Makefile\n\tperl -pi -e \"s/EXTRAVERSION =.*/EXTRAVERSION = $EXTRAVERSION/\" Makefile\n\tgit-diff-index -m -p $RELTREE | gzip -9 > $STAGE/patch-$CURNAME.gz\n\t...\n\nSo this is how to do keyword substitution in a _sane_ way.\n\nSure, we could do something like this as a git script, and support it \n\"natively\", but the fact is, keyword substitution is just stupid.\n\n\t\tLinus\n"},{"id":"28462","messageId":"46a038f90610091408y29f60a12gea7040b5412331c6@mail.gmail.com","threadId":"5860","inReplyTo":"Pine.LNX.4.64.0610090904360.3952@g5.osdl.org","subject":"Re: Does GIT has vc keywords like CVS/Subversion?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-10-09T21:08:15Z","receivedAt":"2006-10-09T21:08:15Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/10/06, Linus Torvalds wrote:\n> So:\n> - inside of the SCM, keyword substitution is pointless, since you have\n> much better tools available (like \"git log filename\")\n> - outside of the SCM, keyword substitution can make sense, but doing it\n> should be in helper scripts or something that can easily tailor it for\n> the actual need of that particular project.\n\nFor the outside of the SCM case, keyword subst is useful indeed if\nsomeone has a $version_unknown tarball, unpacks it and hacks away. It\nis a pretty broken scenario, and less likely to happen nowadays with\neasy access to SCM tools.\n\nHowever, I don't think that scenario is hard to support and Git can\nhave a much better story to tell than keyword substituting SCMs.\n\nIf we have a tool that I can pass a file or a directory tree and will\nfind the (perfectly|closely) matching trees and related commits.\n\nFor the single file case, searching for an exact SHA1 match is easy,\nas is by path. If we get a file without a path it gets a bit harder --\nis there a way to scan the object store for blobs of around a given\nsize (as the packing code does) from Perl? Actually, if we find a\nrelatively close match, it'd be useful to ask git if it's deltified\nand ask for other members of the delta chain.\n\nFor the directory tree case, the ideal thing would be to build a\ntemporary index without getting the blobs in the object store, and\nthen do a first pass trying to match tree SHA1s. If the user has\nmodified a few files in a large project, it'll be trivial to find a\ngood candidate commit for delta. OTOH, if the user has indulged in\nwide ranging search and replace... it will be well deserved pain ;-)\n\ncheers,\n\n\n\nmartin\n"},{"id":"28466","messageId":"Pine.LNX.4.63.0610100045430.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5860","inReplyTo":"46a038f90610091408y29f60a12gea7040b5412331c6@mail.gmail.com","subject":"Re: Does GIT has vc keywords like CVS/Subversion?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-09T22:48:53Z","receivedAt":"2006-10-09T22:48:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 10 Oct 2006, Martin Langhoff wrote:\n\n> On 10/10/06, Linus Torvalds wrote:\n>\n> > - outside of the SCM, keyword substitution can make sense, but doing it\n> > should be in helper scripts or something that can easily tailor it for\n> > the actual need of that particular project.\n\n... like a pre-commit hook.\n\n> If we have a tool that I can pass a file or a directory tree and will \n> find the (perfectly|closely) matching trees and related commits.\n> \n> For the single file case, searching for an exact SHA1 match is easy,\n> as is by path.\n\nIf you have the path, you can reuse the whole algorithm for finding the \nbest delta base.\n\nHowever, if you do not have the path, you might as well just give up (if \nthere is no perfect match for the SHA1), since the SHA1 is _not_ similar \nfor similar contents. IOW, you'd literally have to search _all_ objects in \nthe repository, which usually takes a long, long time.\n\nCiao,\nDscho\n"},{"id":"28468","messageId":"7vmz859k0x.fsf@assigned-by-dhcp.cox.net","threadId":"5860","inReplyTo":"46a038f90610091408y29f60a12gea7040b5412331c6@mail.gmail.com","subject":"Re: Does GIT has vc keywords like CVS/Subversion?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-09T22:55:26Z","receivedAt":"2006-10-09T22:55:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\n\"Martin Langhoff\" writes:\n\n> is there a way to scan the object store for blobs of around a given\n> size (as the packing code does) from Perl?\n\nFor objects in packs, verify-pack -v comes to mind (show-index\nmight show the same information). Loose objects needs help from\ngit-cat-file -s or git-cat-file -t or both.\n"},{"id":"28469","messageId":"46a038f90610091557l2dcfb7bbn7fe2c512af7c4f3c@mail.gmail.com","threadId":"5860","inReplyTo":"Pine.LNX.4.63.0610100045430.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Does GIT has vc keywords like CVS/Subversion?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-10-09T22:57:25Z","receivedAt":"2006-10-09T22:57:25Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/10/06, Johannes Schindelin wrote:\n> If you have the path, you can reuse the whole algorithm for finding\n> the best delta base.\n\nCan I do that from Perl/bash? (how?)\n\n> However, if you do not have the path, you might as well just give up (if\n> there is no perfect match for the SHA1), since the SHA1 is _not_ similar\n> for similar contents. IOW, you'd literally have to search _all_ objects in\n> the repository, which usually takes a long, long time.\n\nSo the delta base algorithm doesn't work without a path. I thought we\nhad a quick way to find blobs of similar size. If the user can't even\ngive us a filename (that we can use to try and build a likely path)\nthen they have bigger problems than the delta ;-) -- at some point we\nhave to provide git-paddedcell for the remaining users.\n\ncheers,\n\n\nmaritn\n"},{"id":"28499","messageId":"452B4DD5.6060508@lsrfire.ath.cx","threadId":"5860","inReplyTo":"46a038f90610091408y29f60a12gea7040b5412331c6@mail.gmail.com","subject":"Re: Does GIT has vc keywords like CVS/Subversion?","fromName":"Rene Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2006-10-10T07:37:57Z","receivedAt":"2006-10-10T07:37:57Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Martin Langhoff schrieb:\n> For the outside of the SCM case, keyword subst is useful indeed if\n> someone has a $version_unknown tarball, unpacks it and hacks away. It\n> is a pretty broken scenario, and less likely to happen nowadays with\n> easy access to SCM tools.\n\nIf you still have the tar file, and if it has been created using\ngit-archive or git-tar-tree it may contain the commit ID in an archive\ncomment. You can use git-get-tar-commit-id to extract it in that case.\n\nThis won't work with official git project tarballs btw., as commit ID\nembedding has been turned off. The reason is that older tar versions\nextracted the comment as a regular file, which confused users.\n\nRené\n"},{"id":"28520","messageId":"20061010164927.GC16412@spearce.org","threadId":"5860","inReplyTo":"46a038f90610091408y29f60a12gea7040b5412331c6@mail.gmail.com","subject":"Re: Does GIT has vc keywords like CVS/Subversion?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-10T16:49:27Z","receivedAt":"2006-10-10T16:49:27Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Martin Langhoff wrote:\n> However, I don't think that scenario is hard to support and Git can\n> have a much better story to tell than keyword substituting SCMs.\n> \n> If we have a tool that I can pass a file or a directory tree and will\n> find the (perfectly|closely) matching trees and related commits.\n> \n> For the single file case, searching for an exact SHA1 match is easy,\n> as is by path. If we get a file without a path it gets a bit harder --\n> is there a way to scan the object store for blobs of around a given\n> size (as the packing code does) from Perl? Actually, if we find a\n> relatively close match, it'd be useful to ask git if it's deltified\n> and ask for other members of the delta chain.\n\ngit-verify-pack -v will print every SHA1, its type and its\ndecompressed size. It also prints who its delta base is. Its also\nnot very fast. However if you run that on a pack file once and\ncache the result then you have much of the data you are looking for.\n\nYou can find objects within a margin of error of the blob size,\nthen find all objects in those delta chains. Then start fetching\nthose objects and comparing contents. But this is brutal and will\ntake a long time due to the sheer number of objects that probably\nwould fall into that size bucket.\n\nThe single file case without a path is not an easy problem. Even if\nyou have an exact SHA1 match (an unmodified file) its difficult\nto find what commits used that SHA1 somewhere within their trees.\nYou need to unpack every tree in every commit and test every\nentry for a match. That's going to take a while on any decent\nsized repository.\n\nMost maintainers would just toss the modified file pack at the sender\nand say \"Uh, where did this file come from?!\" And rightly so.\n\nA maintainer familiar with that section of the repository might\nrecognize some of the file contents and be able to guess the\nfilename. So in short I don't think the single file case without\nfilename is doable, and I don't think its very useful either.\n \n> For the directory tree case, the ideal thing would be to build a\n> temporary index without getting the blobs in the object store, and\n> then do a first pass trying to match tree SHA1s. If the user has\n> modified a few files in a large project, it'll be trivial to find a\n> good candidate commit for delta. OTOH, if the user has indulged in\n> wide ranging search and replace... it will be well deserved pain ;-)\n\nYou have a chance in the tree case. If you have the entire tree\nas a working directory and the modifications made are limited to\na handful of paths then you can load that working directory into a\nset of tree objects and perform a match process by walking backwards\nthrough the commit chains looking for trees which have a high number\nof paths in common with the working directory.\n\nUnfortunately this also has limited use (but I have one myself!).\nIf you got the entire working directory from a submitter than that\nimplies they took your entire distribution, unpacked it, hacked away,\nrepacked it and sent you the tar/zip file. That's significantly\nlarger than a simple patch file produced by diff -R. As a maintainer\nyou probably should be kicking that back at the user and saying\n\"Uh, please submit a patch instead, thanks.\"\n\n\nI actually have a scenario where I'm using Git to track another\n(much, much crappier) file revision storage tool that would probably\nbenefit from this, but the benefit is relatively low.\n\nI'm completely unable to read that tool's version data. The only\nthing I can get from that tool is a snapshot of files as they exist\nat the point in time that I am running the snapshot. The snapshots\naren't always consistent with themselves. Worse they take upwards\nof 30 minutes to run, can only run on a Windows desktop, and consume\n100% of the CPU while running. So we cannot get them very often.\n\nI have several users working on those files in Git through a common\nshared repository. We send changes to that file revision storage\ntool on a frequent basis, say up to 3-5 times per day. Each such\nchange is basically a squashed merge commit in Git terminology,\nso the fine grained commits in Git aren't being preserved by that\nstorage tool, despite being in our shared Git repository.\n\nMany days later most of the changes the users put into the storage\ntool suddenly appear on the next snapshot we obtain from it. I say\nmost because sometimes the powers that be either don't permit a\nchange to show up in the snapshot and delay it for a while, or\nbecause they actually wanted to include a change but someone fat\nfingered the storage controls and the change got omitted. Yet the\npowers that be *believe* the change is included, right up through\ntesting accusing development of not fixing the bug despite the fix\nbeing there in the file revision storage tool.\n\nNow I'd like to take these snapshots every so often, load them\ninto Git on a special branch just for the snapshots, then generate\na merge commit on that branch which merges the real commit that\ncorresponds as closely as possible to to this snapshot into the\nsnapshot branch. Part of the reason for doing this is to look\nfor unexpected differences between what Git has and what the file\nrevision storage tool has.\n\nBut doing that is nearly impossible, so I don't.\n\n-- \nShawn.\n"},{"id":"28521","messageId":"Pine.LNX.4.64.0610101005420.3952@g5.osdl.org","threadId":"5860","inReplyTo":"20061010164927.GC16412@spearce.org","subject":"Re: Does GIT has vc keywords like CVS/Subversion?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-10T17:14:54Z","receivedAt":"2006-10-10T17:14:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 10 Oct 2006, Shawn Pearce wrote:\n> \n> Now I'd like to take these snapshots every so often, load them\n> into Git on a special branch just for the snapshots, then generate\n> a merge commit on that branch which merges the real commit that\n> corresponds as closely as possible to to this snapshot into the\n> snapshot branch. Part of the reason for doing this is to look\n> for unexpected differences between what Git has and what the file\n> revision storage tool has.\n> \n> But doing that is nearly impossible, so I don't.\n\nWell, it probably wouldn't be too nasty to try to have a \"find nearest \ncommit\" kind of thing. It's not quite as simple as bisection, but you \ncould probably use a bisection-like algorithm to do something like a \nbinary search to try to guess which tree is the closest. \n\nIn other words, if you just give git a \"range\" of commits to look at, and \nlet a bisection-line thing pick a mid-way point, you can then compare the \nmid-way point and the end-points (more than two) against the target tree, \nand then pick the range that looks \"closer\".\n\nI wouldn't guarantee that it finds the best candidate (since the \"closer\" \nchoice will inevitably not guarantee a monotonic sequence), but I think \nyou could probably most of the time find something that is reasonably \nclose.\n\nIf you do a lot of branching, you'd have to be a lot smarter about it \n(since you'd not have _one_ commit for beginning/end), but in a \nstraight-line tree it should be really trivial, and in a branchy one I \nthink it should still be quite doable. \n\nI dunno. It might be useful even if it's just a heuristic, in a \"try to \nfind a commit in the range X..Y that generates the smallest diff when \ncompared against this tree\". If it finds something sucky, you can try to \nlook at the history of one of the files that generates a big diff, and try \nto give a better range - the automation should hopefully have given you \n_some_ clues.\n\n\t\tLinus\n"},{"id":"28523","messageId":"7vy7ro2hmu.fsf@assigned-by-dhcp.cox.net","threadId":"5860","inReplyTo":"Pine.LNX.4.64.0610101005420.3952@g5.osdl.org","subject":"Re: Does GIT has vc keywords like CVS/Subversion?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-10T17:41:13Z","receivedAt":"2006-10-10T17:41:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Well, it probably wouldn't be too nasty to try to have a \"find nearest \n> commit\" kind of thing. It's not quite as simple as bisection, but you \n> could probably use a bisection-like algorithm to do something like a \n> binary search to try to guess which tree is the closest. \n\nI had to do something like that in my day job once. A customer\ninstallation was made from a tarball of unknown vintage, and\nthen field patched with later fixes.\n\nI ended up slurping the thing back and populated my index with\nit. Luckily I could guess a good initial point to find the\ncommit that gives minimum \"git diff\" output. Then from the\nremaining patches it was reasonably easy to find out which\nchanges were cherry-picked by hand with \"git log master --\n$paths\".\n"}]}