{"thread":{"id":"18746","subject":"Fetching SHA id's instead of named references?","startedAt":"2009-04-06T12:13:04Z","lastAt":"2009-04-08T20:38:52Z","messageCount":15,"participants":["Klas Lindberg","Johannes Schindelin","Matthieu Moy","Finn Arne Gangstad","Shawn O. Pearce","Nicolas Pitre","Dmitry Potapov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"110560","messageId":"33f4f4d70904060513k320fb6a0ya928c714dcd11e89@mail.gmail.com","threadId":"18746","inReplyTo":null,"subject":"Fetching SHA id's instead of named references?","fromName":"Klas Lindberg","fromEmail":"klas.lindberg@gmail.com","sentAt":"2009-04-06T12:13:04Z","receivedAt":"2009-04-06T12:13:04Z","isPatch":false,"sender":{"key":"klas.lindberg@gmail.com","avatar":null},"body":"Hello\n\nIs there a way to fetch based on SHA id's instead of named references?\n\nMy usage scenario is this: A change management tool based on version\ncontrolled manifest files (somewhat similar to Google's Repo) must be\nable to check out exact versions of all 200 trees in the project view.\nTo support this, tags are used since they specify an exact revision.\nBut there are two problems with tagging:\n\n * Tags are not immutable.\n * External components that already have a tagging style get polluted\nby our excessive use of tags.\n\nI would really prefer to just list SHA keys in the manifests, but\nfetch apparently doesn't support that? Could I use a combination of\nlower level commands instead?\n\nBR / Klas\n"},{"id":"110561","messageId":"alpine.DEB.1.00.0904061431020.6619@intel-tinevez-2-302","threadId":"18746","inReplyTo":"33f4f4d70904060513k320fb6a0ya928c714dcd11e89@mail.gmail.com","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-04-06T12:33:03Z","receivedAt":"2009-04-06T12:33:03Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 6 Apr 2009, Klas Lindberg wrote:\n\n> Is there a way to fetch based on SHA id's instead of named references?\n\nNo, out of security concerns; imagine you included some proprietary \nsource code by mistake, and undo the damage by forcing a push with a \nbranch that does not have the incriminating code. Usually you do not \ncontrol the garbage-collection on the server, yet you still do not want \nother people to fetch \"by SHA-1\".\n\nBTW this is really a strong reason not to use HTTP push in such \nenvironments.\n\nCiao,\nDscho\n"},{"id":"110562","messageId":"33f4f4d70904060541s6dfb7e8ctf50f5e8a872ae1c@mail.gmail.com","threadId":"18746","inReplyTo":"alpine.DEB.1.00.0904061431020.6619@intel-tinevez-2-302","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Klas Lindberg","fromEmail":"klas.lindberg@gmail.com","sentAt":"2009-04-06T12:41:26Z","receivedAt":"2009-04-06T12:41:26Z","isPatch":false,"sender":{"key":"klas.lindberg@gmail.com","avatar":null},"body":"Hello\n\nThank you, but I don't understand the answer. If I mistakenly publish\na tree that contains secrets and someone manages to fetch against it\nbefore I correct the mistake; how does the limitation to only fetch\nnamed references help me???\n\nBy the way: I don't use push. I'd be perfectly happy if just fetch\nsupported SHA key references.\n\nBR / Klas\n\n\nOn Mon, Apr 6, 2009 at 2:33 PM, Johannes Schindelin\n wrote:\n> Hi,\n>\n> On Mon, 6 Apr 2009, Klas Lindberg wrote:\n>\n>> Is there a way to fetch based on SHA id's instead of named references?\n>\n> No, out of security concerns; imagine you included some proprietary\n> source code by mistake, and undo the damage by forcing a push with a\n> branch that does not have the incriminating code. Usually you do not\n> control the garbage-collection on the server, yet you still do not want\n> other people to fetch \"by SHA-1\".\n>\n> BTW this is really a strong reason not to use HTTP push in such\n> environments.\n>\n> Ciao,\n> Dscho\n>\n"},{"id":"110564","messageId":"alpine.DEB.1.00.0904061447220.6619@intel-tinevez-2-302","threadId":"18746","inReplyTo":"33f4f4d70904060541s6dfb7e8ctf50f5e8a872ae1c@mail.gmail.com","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-04-06T12:48:17Z","receivedAt":"2009-04-06T12:48:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 6 Apr 2009, Klas Lindberg wrote:\n\n> Thank you, but I don't understand the answer. If I mistakenly publish a \n> tree that contains secrets and someone manages to fetch against it \n> before I correct the mistake; how does the limitation to only fetch \n> named references help me???\n\nThe issue is not if someone manages to fetch stuff before you repair it. \nThe issue is that that someone should not be able to manage _after_ you \nrepair it.\n\nOh, and please do not top-post,\nDscho\n"},{"id":"110565","messageId":"vpqprfq3ptb.fsf@bauges.imag.fr","threadId":"18746","inReplyTo":"33f4f4d70904060541s6dfb7e8ctf50f5e8a872ae1c@mail.gmail.com","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-04-06T12:54:40Z","receivedAt":"2009-04-06T12:54:40Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Klas Lindberg writes:\n\n> Hello\n>\n> Thank you, but I don't understand the answer. If I mistakenly publish\n> a tree that contains secrets and someone manages to fetch against it\n> before I correct the mistake; how does the limitation to only fetch\n> named references help me???\n\nWhat Johannes pointed out is that someone could fetch from your repo\n_after_ you correct the mistake (if you don't control garbage\ncollection).\n\n-- \nMatthieu\n"},{"id":"110567","messageId":"33f4f4d70904060606h4d014fbdibe195a83233d8899@mail.gmail.com","threadId":"18746","inReplyTo":"vpqprfq3ptb.fsf@bauges.imag.fr","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Klas Lindberg","fromEmail":"klas.lindberg@gmail.com","sentAt":"2009-04-06T13:06:46Z","receivedAt":"2009-04-06T13:06:46Z","isPatch":false,"sender":{"key":"klas.lindberg@gmail.com","avatar":null},"body":"On Mon, Apr 6, 2009 at 2:54 PM, Matthieu Moy wrote:\n\n> What Johannes pointed out is that someone could fetch from your repo\n> _after_ you correct the mistake (if you don't control garbage\n> collection).\n\nAha, ok. But how then does submodule update work? Git will only see\nSHA keys for each submodule in the cotntainer tree commit, so how does\nit perform fetching of those (unnamed) references?\n\nBR / Klas\n"},{"id":"110569","messageId":"20090406131643.GA16229@pvv.org","threadId":"18746","inReplyTo":"33f4f4d70904060606h4d014fbdibe195a83233d8899@mail.gmail.com","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2009-04-06T13:16:43Z","receivedAt":"2009-04-06T13:16:43Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Mon, Apr 06, 2009 at 03:06:46PM +0200, Klas Lindberg wrote:\n> On Mon, Apr 6, 2009 at 2:54 PM, Matthieu Moy wrote:\n> \n> > What Johannes pointed out is that someone could fetch from your repo\n> > _after_ you correct the mistake (if you don't control garbage\n> > collection).\n> \n> Aha, ok. But how then does submodule update work? Git will only see\n> SHA keys for each submodule in the cotntainer tree commit, so how does\n> it perform fetching of those (unnamed) references?\n\ngit submodule update just does \"git fetch\" and hopes that the required\ncommit appears. In practice this means that you (may) need to invent a\ntag or a branch for all the submodules, otherwise they are not\nfetchable.\n\nThis bit us pretty hard when we tried to use submodules earlier, so we\ngave up. Maybe some day...\n\n- Finn Arne\n"},{"id":"110587","messageId":"20090406144047.GE23604@spearce.org","threadId":"18746","inReplyTo":"alpine.DEB.1.00.0904061431020.6619@intel-tinevez-2-302","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-04-06T14:40:47Z","receivedAt":"2009-04-06T14:40:47Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Mon, 6 Apr 2009, Klas Lindberg wrote:\n> \n> > Is there a way to fetch based on SHA id's instead of named references?\n> \n> No, out of security concerns; imagine you included some proprietary \n> source code by mistake, and undo the damage by forcing a push with a \n> branch that does not have the incriminating code. Usually you do not \n> control the garbage-collection on the server, yet you still do not want \n> other people to fetch \"by SHA-1\".\n> \n> BTW this is really a strong reason not to use HTTP push in such \n> environments.\n\nErr, you mean http:// and rsync:// fetch, don't you? Because if\nyou rely on being able to unpublish a ref you have to use only the\nnative git://, where direct access is otherwise forbidden.\n\nAnyway.\n\nThe fetch-pack/upload-pack protocol uses SHA1s in the want commands,\nso in theory at the protocol level you can say \"git fetch URL SHA1\"\nand convey your request to the remote peer.\n\nThe problem is, upload-pack won't perform a reachability analysis\nto determine if a wanted SHA1 is reachable from a current ref.\nInstead it requires that the wanted SHA1 is *exactly* referenced\nby at least one ref.\n\nI had previously proposed adding a merge base test if SHA1 parses\nas a commit, but IIRC Junio rejected the idea, saying it was too\ncostly to perform on the server.\n\nThe thing is, he's right.\n\nThere's no reason to perform the reachability test on the server\nwhen you can move it onto the client, and that's exactly what\ngit-submodule is doing. It fetches everything, and then assumes\nits reachable post fetch. Since the client has fetched everything,\nthe client has the object if its reachable by the server.\n\nIf the object is no longer reachable by the server's refs (think\nbranch rebased) then the object is actually in danger of being GC'd\noff of the server's object store. So you already are going to be\nplaying with fire, even if we added a server side config to permit\nfetching of unreachable data. A future \"git gc\" on that server\nrepository could suddenly wipe out that data entirely.\n\n\nKlas, one suggestion might be to make a \"refs/heads/world\" ref which\nhas a threaded chain of merges of every commit you ever recorded\nin the supermodule, and then you can assume post fetch that the\nworld is reachable.\n\nE.g. every time you want to record a commit in the manifest file,\nalso shove it into the world:\n\n C=...commit.to.save... &\n W=$(git rev-parse refs/heads/world) &&\n git update-ref refs/heads/world \\\n $(echo Save $C, save the world | git commit-tree $W -p $W -p $C) \\\n $W &&\n git push URL refs/heads/world\n\nOne way we get away with this sort of thing in repo is, we only\nput SHA1s in our manifest that are published in branches that\nwon't ever rewind or delete. Hence, its a moot point.\n\n-- \nShawn.\n"},{"id":"110599","messageId":"33f4f4d70904060922t5c868ec0x89ed5891cf4b19c2@mail.gmail.com","threadId":"18746","inReplyTo":"20090406144047.GE23604@spearce.org","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Klas Lindberg","fromEmail":"klas.lindberg@gmail.com","sentAt":"2009-04-06T16:22:15Z","receivedAt":"2009-04-06T16:22:15Z","isPatch":false,"sender":{"key":"klas.lindberg@gmail.com","avatar":null},"body":"On Mon, Apr 6, 2009 at 4:40 PM, Shawn O. Pearce wrote:\n\n> The problem is, upload-pack won't perform a reachability analysis\n> to determine if a wanted SHA1 is reachable from a current ref.\n> Instead it requires that the wanted SHA1 is *exactly* referenced\n> by at least one ref.\n\nI probably just don't understand this properly, so please correct me\nas needed. My understanding is that\n\n * git-fetch-pack looks at the local named reference to figure out the\nSHA id \"X\" for the last locally available commit.\n * git-upload-pack is given \"X\" as a delimiter for what to include in\nthe pack to send back to git-fetch-pack.\n\nSo if I have \"X\" and I know which remote \"Y\" I want (because someone\ntold me, or it's in a manifest), why shouldn't I be able to let\ngit-upload-pack search for \"X\" from \"Y\" if that is exactly what it\ndoes anyway for named references? I accept that it may fail because\n\"X\" is not reachable from \"Y\" (just give me a sensible error message).\n\n> There's no reason to perform the reachability test on the server\n> when you can move it onto the client, and that's exactly what\n> git-submodule is doing. It fetches everything, and then assumes\n> its reachable post fetch. Since the client has fetched everything,\n> the client has the object if its reachable by the server.\n\nExcept it will not always be available even when it was reachable at\nthe source. Here's the real world example that forced me to reject the\nuse of the submodule command for distributed setups:\n\n * Bob is located at site S where he sets up tree A with a submodule\nB. He uses \"submodule init\" to initialize B, which will cause it to be\nlisted relative to S in A.\n * Lisa, at site T, clones A and updates the submodule B. No problem\nso far. Her list of submodules is inherited from S and works for\nupdating B.\n * Lisa commits a new version of B and then a new version of A. Then\nshe asks Kent to merge her changes.\n * Kent's clone will also have a submodules list that refers to site S\n(and not T). Running \"submodule update\" after fetching from T fails\neven though all the material is available at T, because Git is then\ntrying to fetch the new revision of B from S.\n\nIf you try to work around this by not using \"submodule init\", then you\nget a saner tree that can be worked on in a truly serverless fashion,\nlike with plain git trees, but you have to implement a CM tool on top.\n\n> If the object is no longer reachable by the server's refs (think\n> branch rebased) then the object is actually in danger of being GC'd\n> off of the server's object store.\n\nThis is alright and I would make sure all the refs I want to keep are\nreachable from named references to keep git-gc from chomping stuff in\nmy local tree.\n\nIn the remote tree, the unnamed reference is either available or it\nisn't. If someone made an unnamed reference unreachable and then\ngarbage-collected it, well so be it. Just tell the user that the\nreference can't be found and may in fact not exist at all and you're\ndone. No exhaustive search necessary.\n\n> One way we get away with this sort of thing in repo is, we only\n> put SHA1s in our manifest that are published in branches that\n> won't ever rewind or delete. Hence, its a moot point.\n\nWhat is the syntax for that?\n\nAnyway it's not a moot point. I may later want to use that revision of\nthe manifest to perform a checkout on every component listed by the\nmanifest. At that point I expect all the work trees to have exactly\nthe contents they \"should\" have for that old version of the manifest.\nIt's all about affordable reproducibility.\n\n/Klas\n"},{"id":"110604","messageId":"alpine.LFD.2.00.0904061245111.6741@xanadu.home","threadId":"18746","inReplyTo":"33f4f4d70904060922t5c868ec0x89ed5891cf4b19c2@mail.gmail.com","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-04-06T16:55:46Z","receivedAt":"2009-04-06T16:55:46Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 6 Apr 2009, Klas Lindberg wrote:\n\n> In the remote tree, the unnamed reference is either available or it\n> isn't. If someone made an unnamed reference unreachable and then\n> garbage-collected it, well so be it. Just tell the user that the\n> reference can't be found and may in fact not exist at all and you're\n> done. No exhaustive search necessary.\n\nWhy can't you simply fetch the remote from its branch tip and then \nfigure out / checkout the particular unnamed reference you wish locally?\n\n> I may later want to use that revision of the manifest to perform a \n> checkout on every component listed by the manifest. At that point I \n> expect all the work trees to have exactly the contents they \"should\" \n> have for that old version of the manifest. It's all about affordable \n> reproducibility.\n\nUnlike with CVS/SVN, you don't need anything from the remote if you want \nto checkout an old version. In particular, there is no need for you to \nonly fetch that old version from the remote. You just fetch everything \nfrom the remote and then checkout the particular old version you wish. \nThere is just no real advantage to limit yourself to some old version \nfrom the remote repository because that's what you want locally. Sure \nyou might be getting more data than needed, but usually not that much \ndue to git's good delta compression making extra versions almost free.\n\n\nNicolas\n"},{"id":"110634","messageId":"37fcd2780904061450t62cac214x7588e056a6450bab@mail.gmail.com","threadId":"18746","inReplyTo":"alpine.DEB.1.00.0904061447220.6619@intel-tinevez-2-302","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-04-06T21:50:36Z","receivedAt":"2009-04-06T21:50:36Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Apr 06, 2009 at 02:48:17PM +0200, Johannes Schindelin wrote:\n>_\n> The issue is not if someone manages to fetch stuff before you repair it.__\n> The issue is that that someone should not be able to manage _after_ you_\n> repair it.\n\nBut how this someone will know the exact SHA-1 needed to fetch this\ncommit without having seen this commit already? Guessing SHA-1 by\nbrute force attack does not sound very promising...\n\nDmitry\n"},{"id":"110642","messageId":"33f4f4d70904061640j1b03c499x1765da1a72a411f3@mail.gmail.com","threadId":"18746","inReplyTo":"alpine.LFD.2.00.0904061245111.6741@xanadu.home","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Klas Lindberg","fromEmail":"klas.lindberg@gmail.com","sentAt":"2009-04-06T23:40:04Z","receivedAt":"2009-04-06T23:40:04Z","isPatch":false,"sender":{"key":"klas.lindberg@gmail.com","avatar":null},"body":"On Mon, Apr 6, 2009 at 6:55 PM, Nicolas Pitre wrote:\n\n> Why can't you simply fetch the remote from its branch tip and then\n> figure out / checkout the particular unnamed reference you wish locally?\n\nIt is a pretty sane thing to do, but it makes me a bit nervous that\nbranches are not immutable. Let's say I decide on a manifest format\nwhere each tree is listed as a branch name plus the current SHA key on\nthat branch. The branch name is needed to enable fetch, but if the\nbranch is later renamed because of a change in naming policy, or its\nname simply reused to refer to something completely different (*),\nthen there is no guarantee that the SHA key is reachable through that\nbranch name.\n\n(*) These situations cannot be discounted in an organization with,\nsay, a few thousand employees and several tens of really big projects\nwith considerable overlap. I have to take into account that the right\nhand may not know what the left hand is doing all the time.\n\n> Unlike with CVS/SVN, you don't need anything from the remote if you want\n> to checkout an old version. In particular, there is no need for you to\n> only fetch that old version from the remote.  You just fetch everything\n> from the remote and then checkout the particular old version you wish.\n\nPlease consider when you have to recreate some particular forest that\nyou never worked on before, but now you have to fetch and recreate a 3\nyear old version so that you can work on that critical error report.\nAnd I may really not want to fetch everything. Some projects are just\nvery very big.\n\nI think that what I would need is either\n\n * Immutable tags, or\n * A way to maintain sets of indestructible commits based on SHA id's\nand a way to fetch them without going through a named reference.\n\nThe second option seems better because it would allow for recursion on\nsubmodules and it doesn't pollute the tag name space.\n\nBR / Klas\n"},{"id":"110650","messageId":"alpine.LFD.2.00.0904062214170.6741@xanadu.home","threadId":"18746","inReplyTo":"33f4f4d70904061640j1b03c499x1765da1a72a411f3@mail.gmail.com","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-04-07T02:34:36Z","receivedAt":"2009-04-07T02:34:36Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 7 Apr 2009, Klas Lindberg wrote:\n\n> On Mon, Apr 6, 2009 at 6:55 PM, Nicolas Pitre wrote:\n> \n> > Why can't you simply fetch the remote from its branch tip and then\n> > figure out / checkout the particular unnamed reference you wish locally?\n> \n> It is a pretty sane thing to do, but it makes me a bit nervous that\n> branches are not immutable. Let's say I decide on a manifest format\n> where each tree is listed as a branch name plus the current SHA key on\n> that branch. The branch name is needed to enable fetch, but if the\n> branch is later renamed because of a change in naming policy, or its\n> name simply reused to refer to something completely different (*),\n> then there is no guarantee that the SHA key is reachable through that\n> branch name.\n\nIn git terms, this is called \"history rewriting\". And you really don't \nwant to do that if your repository is pulled by other people, unless \nthere is an explicit statement about that fact.\n\nStill, if you fetch all branches from the remote (which is the default \nbehavior anyway), then the branch you're interested in will always \ncontain the particular commit you're looking for, regardless of the name \nof the branch. While it is true that branches may not be immutable, any \ncommit they collectively refer to still are immutable.\n\nIf the remote has deleted the only branch through which your particular \ncommit of interest was reachable, then of course pulling all branches \nfrom the remote won't hhelp you. But nor would a fetch with the \nparticular commit's SHA1 because it may well have been pruned from the \nremote repository at that point.\n\n> (*) These situations cannot be discounted in an organization with,\n> say, a few thousand employees and several tens of really big projects\n> with considerable overlap. I have to take into account that the right\n> hand may not know what the left hand is doing all the time.\n\nThing is, with the distributed nature of git, nothing prevents you from \nkeeping a local version of the commit you're interested in. Unlike with \na central repository where someone else might delete a branch you need, \nwith git you will still have access to that particular commit locally \nregardless if the remote repository has deleted it or not.\n\n> > Unlike with CVS/SVN, you don't need anything from the remote if you want\n> > to checkout an old version. In particular, there is no need for you to\n> > only fetch that old version from the remote.  You just fetch everything\n> > from the remote and then checkout the particular old version you wish.\n> \n> Please consider when you have to recreate some particular forest that\n> you never worked on before, but now you have to fetch and recreate a 3\n> year old version so that you can work on that critical error report.\n> And I may really not want to fetch everything. Some projects are just\n> very very big.\n\nThere is nothing a tool can do for you if someone is determined to be \nstupid with it. In other words, don't delete a branch if it contains \nimportant stuff. You may rename it if you wish. And if you don't want \nto fetch everything then you may always find out about the right branch \nto pull with \"git branch --contains \".\n\n> I think that what I would need is either\n> \n> * Immutable tags, or\n> * A way to maintain sets of indestructible commits based on SHA id's\n> and a way to fetch them without going through a named reference.\n> \n> The second option seems better because it would allow for recursion on\n> submodules and it doesn't pollute the tag name space.\n\nMaybe. But as others already explained, there are technical reasons \nthat makes such a solution undesirable.\n\n\nNicolas\n"},{"id":"110867","messageId":"4CBB910C-24F5-4F51-A02D-7760839CCE18@gmail.com","threadId":"18746","inReplyTo":"alpine.LFD.2.00.0904062214170.6741@xanadu.home","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Klas Lindberg","fromEmail":"klas.lindberg@gmail.com","sentAt":"2009-04-08T20:03:49Z","receivedAt":"2009-04-08T20:03:49Z","isPatch":false,"sender":{"key":"klas.lindberg@gmail.com","avatar":null},"body":"7 apr 2009 kl. 04.34 skrev Nicolas Pitre:\n\n> In git terms, this is called \"history rewriting\". And you really \n> don't\n> want to do that if your repository is pulled by other people, unless\n> there is an explicit statement about that fact.\n\nI thought you had to use filter-branch to qualify for history \nrewriting? Anyway, the scenario I have in mind is when a new branch is \ncreated from the old one, the old one deleted and then the name of the \nold one gets reused. The deltas are still there, intact, but now you \nhave to use a different named reference to reach them :-(\n\n> Thing is, with the distributed nature of git, nothing prevents you \n> from\n> keeping a local version of the commit you're interested in. Unlike \n> with\n> a central repository where someone else might delete a branch you \n> need,\n> with git you will still have access to that particular commit locally\n> regardless if the remote repository has deleted it or not.\n\nThis is true, and Git is indeed very good at saving your ass on the \nclient side. Other systems spend much more effort on saving your ass \non the server side. My problem is that \"my\" people responsible for the \noverall system are mostly interested in the server side. At least that \nis where they put the tough requirements on perpetual availability.\n\nHowever, it is good enough if there is some way to somehow guarantee \nthat a branch or tag will never be misused as outlined above. This \ncould be solved through basic file system mechanisms (like write \nprotecting the refs/tags files perhaps?) or a backup mechanism that \nraises an alarm on forbidden manipulations, or a host of other more or \nless weird mechanisms. Git doesn't have to provide the mechanism \ndirectly, but it would be nice for enterprise users if it did.\n\n> There is nothing a tool can do for you if someone is determined to be\n> stupid with it. In other words, don't delete a branch if it contains\n> important stuff. You may rename it if you wish. And if you don't \n> want\n> to fetch everything then you may always find out about the right \n> branch\n> to pull with \"git branch --contains \".\n\nThis is all very true. And I wasn't aware of the --contains switch \nbefore. That one covers an entire scenario for me. Thanks!!\n\nBR / Klas\n"},{"id":"110868","messageId":"alpine.LFD.2.00.0904081624410.6741@xanadu.home","threadId":"18746","inReplyTo":"4CBB910C-24F5-4F51-A02D-7760839CCE18@gmail.com","subject":"Re: Fetching SHA id's instead of named references?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-04-08T20:38:52Z","receivedAt":"2009-04-08T20:38:52Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 8 Apr 2009, Klas Lindberg wrote:\n\n> 7 apr 2009 kl. 04.34 skrev Nicolas Pitre:\n> \n> > In git terms, this is called \"history rewriting\". And you really don't\n> > want to do that if your repository is pulled by other people, unless\n> > there is an explicit statement about that fact.\n> \n> I thought you had to use filter-branch to qualify for history rewriting?\n\nThat, or 'git rebase', or 'git reset', or 'git commit --amend' on an \nalready published commit, or reusing a branch name for a different line \nof development. Anything that would look like the past has changed to a \nclient fetching from you.\n\n> Anyway, the scenario I have in mind is when a new branch is created from the\n> old one, the old one deleted and then the name of the old one gets reused. The\n> deltas are still there, intact, but now you have to use a different named\n> reference to reach them :-(\n\nRight. And normally you would use a good name for the new branch that \nclearly indicate its archiving purpose.\n\n> > Thing is, with the distributed nature of git, nothing prevents you from\n> > keeping a local version of the commit you're interested in. Unlike with\n> > a central repository where someone else might delete a branch you need,\n> > with git you will still have access to that particular commit locally\n> > regardless if the remote repository has deleted it or not.\n> \n> This is true, and Git is indeed very good at saving your ass on the client\n> side. Other systems spend much more effort on saving your ass on the server\n> side. My problem is that \"my\" people responsible for the overall system are\n> mostly interested in the server side. At least that is where they put the\n> tough requirements on perpetual availability.\n\nJust never allow for any branch to be deleted nor rewound on the server \nthen.\n\n> However, it is good enough if there is some way to somehow guarantee that a\n> branch or tag will never be misused as outlined above. This could be solved\n> through basic file system mechanisms (like write protecting the refs/tags\n> files perhaps?) or a backup mechanism that raises an alarm on forbidden\n> manipulations, or a host of other more or less weird mechanisms. Git doesn't\n> have to provide the mechanism directly, but it would be nice for enterprise\n> users if it did.\n\nGit provides you with hooks. Have a look here:\n\n http://www.kernel.org/pub/software/scm/git/docs/githooks.html\n\n\nNicolas\n"}]}