{"thread":{"id":"10203","subject":"Recording merges after repo conversion","startedAt":"2007-10-09T07:09:36Z","lastAt":"2007-10-31T17:08:49Z","messageCount":21,"participants":["Peter Karlsson","Benoit SIGOURE","Lars Hjemli","Johannes Schindelin","Johan Herland","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"55234","messageId":"Pine.LNX.4.64.0710090807060.26773@ds9.cixit.se","threadId":"10203","inReplyTo":null,"subject":"Recording merges after repo conversion","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-09T07:09:36Z","receivedAt":"2007-10-09T07:09:36Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Hi!\n\nI have a couple of repositories converted from CVS to Git using\nparsecvs. Some are just converted, some I've continued to develop after\nthe conversion (and cloned a couple of times).\n\nSince parsecvs gave me all the CVS branches, I would like to record the\nmerge points in the Git history, if possible. I have commited merges\nwith comments like \"merged <branchname>\", so I can probably find them\nquite easily, and I do have the imported CVS branches available. Can I\nrecord the merge information so git knows about them?\n\nIs it safe to do so on a repository that has already been cloned (i.e,\nwill a later push/pull work)?\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"55235","messageId":"13D1D3DD-9652-4097-8364-DEF4F26540D3@lrde.epita.fr","threadId":"10203","inReplyTo":"Pine.LNX.4.64.0710090807060.26773@ds9.cixit.se","subject":"Re: Recording merges after repo conversion","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-10-09T07:19:28Z","receivedAt":"2007-10-09T07:19:28Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Oct 9, 2007, at 9:09 AM, Peter Karlsson wrote:\n\n> Hi!\n>\n> I have a couple of repositories converted from CVS to Git using\n> parsecvs. Some are just converted, some I've continued to develop  \n> after\n> the conversion (and cloned a couple of times).\n>\n> Since parsecvs gave me all the CVS branches, I would like to record  \n> the\n> merge points in the Git history, if possible. I have commited merges\n> with comments like \"merged <branchname>\", so I can probably find them\n> quite easily, and I do have the imported CVS branches available. Can I\n> record the merge information so git knows about them?\n>\n> Is it safe to do so on a repository that has already been cloned (i.e,\n> will a later push/pull work)?\n\nI think you can use grafts do achieve this.\n\n From Documentation/repository-layout.txt:\ninfo/grafts::\n         This file records fake commit ancestry information, to\n         pretend the set of parents a commit has is different\n         from how the commit was actually created.  One record\n         per line describes a commit and its fake parents by\n         listing their 40-byte hexadecimal object names separated\n         by a space and terminated by a newline.\n\nCheers,\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"57579","messageId":"Pine.LNX.4.62.0710301433150.652@perkele.intern.softwolves.pp.se","threadId":"10203","inReplyTo":"13D1D3DD-9652-4097-8364-DEF4F26540D3@lrde.epita.fr","subject":"Re: Recording merges after repo conversion","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-30T13:34:27Z","receivedAt":"2007-10-30T13:34:27Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Benoit SIGOURE:\n\n> I think you can use grafts do achieve this.\n\nThat seems to work, but the grafts list doesn't seem to propagate when I \npush/pull/clone. Is it possible to get that to work?\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"57581","messageId":"8c5c35580710300729t4a7b375dud01253d9b4ef7196@mail.gmail.com","threadId":"10203","inReplyTo":"Pine.LNX.4.62.0710301433150.652@perkele.intern.softwolves.pp.se","subject":"Re: Recording merges after repo conversion","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-10-30T14:29:44Z","receivedAt":"2007-10-30T14:29:44Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 10/30/07, Peter Karlsson <peter@softwolves.pp.se> wrote:\n> Benoit SIGOURE:\n>\n> > I think you can use grafts do achieve this.\n>\n> That seems to work, but the grafts list doesn't seem to propagate when I\n> push/pull/clone. Is it possible to get that to work?\n>\n\nNo, the grafts file is purely local. To achieve your goal, you'd have\nto 'git filter-branch' before pushing/cloning. But beware: this _will_\nrewrite your current branch(es).\n\n--\nlarsh\n"},{"id":"57585","messageId":"Pine.LNX.4.64.0710301504270.4362@racer.site","threadId":"10203","inReplyTo":"Pine.LNX.4.62.0710301433150.652@perkele.intern.softwolves.pp.se","subject":"Re: Recording merges after repo conversion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-30T15:05:01Z","receivedAt":"2007-10-30T15:05:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 30 Oct 2007, Peter Karlsson wrote:\n\n> Benoit SIGOURE:\n> \n> > I think you can use grafts do achieve this.\n> \n> That seems to work, but the grafts list doesn't seem to propagate when I \n> push/pull/clone. Is it possible to get that to work?\n\nNo.  Use filter-branch, and publish the cleaned up history (possibly as a \nnew branch/repo).\n\nCiao,\nDscho\n"},{"id":"57621","messageId":"Pine.LNX.4.62.0710302204590.6976@perkele.intern.softwolves.pp.se","threadId":"10203","inReplyTo":"8c5c35580710300729t4a7b375dud01253d9b4ef7196@mail.gmail.com","subject":"Re: Recording merges after repo conversion","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-30T21:06:32Z","receivedAt":"2007-10-30T21:06:32Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Lars Hjemli:\n\n> No, the grafts file is purely local.\n\nHmm, any chance that will change in a future version?\n\n> To achieve your goal, you'd have to 'git filter-branch' before \n> pushing/cloning. But beware: this _will_ rewrite your current branch(es).\n\nOuch. I'll have to think about whether I want to do that, then...\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"57625","messageId":"8c5c35580710301446y119f8199u8dce4b500316376a@mail.gmail.com","threadId":"10203","inReplyTo":"Pine.LNX.4.62.0710302204590.6976@perkele.intern.softwolves.pp.se","subject":"Re: Recording merges after repo conversion","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-10-30T21:46:00Z","receivedAt":"2007-10-30T21:46:00Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On Oct 30, 2007 10:06 PM, Peter Karlsson <peter@softwolves.pp.se> wrote:\n> Lars Hjemli:\n>\n> > No, the grafts file is purely local.\n>\n> Hmm, any chance that will change in a future version?\n\nNot likely\n\n>\n> > To achieve your goal, you'd have to 'git filter-branch' before\n> > pushing/cloning. But beware: this _will_ rewrite your current branch(es).\n>\n> Ouch. I'll have to think about whether I want to do that, then...\n\nWell, it isn't dangerous, but if someone has already cloned your repo\n_and_ commited local changes they'll need to rebase their work onto\nthe new branch(es). Basically, you'll want to inform these people that\nyou're going to rewrite the branches.\n\n-- \nlarsh\n"},{"id":"57648","messageId":"Pine.LNX.4.64.0710310227340.4362@racer.site","threadId":"10203","inReplyTo":"Pine.LNX.4.62.0710302204590.6976@perkele.intern.softwolves.pp.se","subject":"Re: Recording merges after repo conversion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-31T02:28:47Z","receivedAt":"2007-10-31T02:28:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 30 Oct 2007, Peter Karlsson wrote:\n\n> Lars Hjemli:\n> \n> > No, the grafts file is purely local.\n> \n> Hmm, any chance that will change in a future version?\n\nWhy should it?  This would contradict the whole \"a commit sha1 hashes the \ncommit, and by inference the _whole_ history\" principle.\n\nCiao,\nDscho\n"},{"id":"57677","messageId":"Pine.LNX.4.62.0710311048450.13264@perkele.intern.softwolves.pp.se","threadId":"10203","inReplyTo":"Pine.LNX.4.64.0710310227340.4362@racer.site","subject":"Re: Recording merges after repo conversion","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-31T09:50:02Z","receivedAt":"2007-10-31T09:50:02Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Johannes Schindelin:\n\n> Why should it?  This would contradict the whole \"a commit sha1 hashes the\n> commit, and by inference the _whole_ history\" principle.\n\nDoes it? Why can't the grafts file itself be committed to the repository and \nlive in the history?\n\nWell, yeah, the SHA1 hashing is one of Git's main strengths, but it also \nopens up some weaknesses.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"57682","messageId":"Pine.LNX.4.64.0710311059020.4362@racer.site","threadId":"10203","inReplyTo":"Pine.LNX.4.62.0710311048450.13264@perkele.intern.softwolves.pp.se","subject":"Re: Recording merges after repo conversion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-31T11:01:28Z","receivedAt":"2007-10-31T11:01:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 31 Oct 2007, Peter Karlsson wrote:\n\n> Johannes Schindelin:\n> \n> > Why should it?  This would contradict the whole \"a commit sha1 hashes \n> > the commit, and by inference the _whole_ history\" principle.\n> \n> Does it?\n\nYes!  Of course!  If what you want becomes possible, I could make an evil \nchange in history long gone, and slip it by you.  You could not even see \nthe history which changed.\n\n> Why can't the grafts file itself be committed to the repository and live \n> in the history?\n\nYou can do that already.  But you have to ask the people at the other end \nto actually apply the graft.\n\n> Well, yeah, the SHA1 hashing is one of Git's main strengths, but it also\n> opens up some weaknesses.\n\nIf you really think that, I doubt you understood the issues at hand.\n\nCiao,\nDscho\n"},{"id":"57665","messageId":"Pine.LNX.4.64.0710311305290.16298@ds9.cixit.se","threadId":"10203","inReplyTo":"Pine.LNX.4.64.0710311059020.4362@racer.site","subject":"Re: Recording merges after repo conversion","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-31T12:07:51Z","receivedAt":"2007-10-31T12:07:51Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"> Yes!  Of course!  If what you want becomes possible, I could make an\n> evil change in history long gone, and slip it by you. You could not\n> even see the history which changed.\n\nI would see the grafts file being changed, which would alert me (the\nproblem I have with graft is that it *replaces* history information for\nan element, not just *add* to it, which threw me off at my first\nattempt at creating one).\n\n> You can do that already.  But you have to ask the people at the other\n> end to actually apply the graft.\n\nLast time I tried, git would not add files that was in the \".git\"\nsubdirectory to version control. I might have done something\nincorrectly, though, so I'll see if it works now.\n\n> If you really think that, I doubt you understood the issues at hand.\n\nI have, I'm just thinking of the issues that are created by solving the\nissues it does solve.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"57681","messageId":"Pine.LNX.4.64.0710311315250.16298@ds9.cixit.se","threadId":"10203","inReplyTo":"Pine.LNX.4.64.0710301504270.4362@racer.site","subject":"Re: Recording merges after repo conversion","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-31T12:17:13Z","receivedAt":"2007-10-31T12:17:13Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Johannes Schindelin:\n\n> No.  Use filter-branch, and publish the cleaned up history (possibly as a \n> new branch/repo).\n\nI'm considering doing this, and just replace the published repository\nwith the \"fixed\" one (and fix-up all my clonings of it). I'm having\nsome problems digesting the git-filter-branch manual page though--is\nthere an easy way of automating the process, given that I now have a\n\"grafts\" file that expresses what I would like git-filter-branch to do\n(I guess it would have to work backwards changing the merge points, to\nbe able to find all the revisions under the names I've used in the\ngrafts file)?\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"57687","messageId":"Pine.LNX.4.64.0710311229560.4362@racer.site","threadId":"10203","inReplyTo":"Pine.LNX.4.64.0710311305290.16298@ds9.cixit.se","subject":"Re: Recording merges after repo conversion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-31T12:32:01Z","receivedAt":"2007-10-31T12:32:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 31 Oct 2007, Peter Karlsson wrote:\n\n> > Yes!  Of course!  If what you want becomes possible, I could make an \n> > evil change in history long gone, and slip it by you. You could not \n> > even see the history which changed.\n> \n> I would see the grafts file being changed, which would alert me (the \n> problem I have with graft is that it *replaces* history information for \n> an element, not just *add* to it, which threw me off at my first attempt \n> at creating one).\n\nThe thing is: it is too easy to overlook a tiny change like this.  And it \nis very, very difficult to see what it _really_ changed.\n\nTherefore I am _strongly_ opposed to changing the current behaviour.\n\n> > You can do that already.  But you have to ask the people at the other \n> > end to actually apply the graft.\n> \n> Last time I tried, git would not add files that was in the \".git\" \n> subdirectory to version control. I might have done something \n> incorrectly, though, so I'll see if it works now.\n\nWell, I was not explicit enough.  You can check in the grafts file _under \na different name_.  Outside of .git/.\n\nHth,\nDscho\n"},{"id":"57688","messageId":"200710311343.58414.johan@herland.net","threadId":"10203","inReplyTo":"Pine.LNX.4.64.0710311059020.4362@racer.site","subject":"Re: Recording merges after repo conversion","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-10-31T12:43:54Z","receivedAt":"2007-10-31T12:43:54Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 31 October 2007, Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 31 Oct 2007, Peter Karlsson wrote:\n> \n> > Johannes Schindelin:\n> > \n> > > Why should it?  This would contradict the whole \"a commit sha1 hashes \n> > > the commit, and by inference the _whole_ history\" principle.\n> > \n> > Does it?\n> \n> Yes!  Of course!  If what you want becomes possible, I could make an evil \n> change in history long gone, and slip it by you.  You could not even see \n> the history which changed.\n\nWell, technically, if the grafts file was part of the repo, you wouldn't be \nable to change the (in-tree) grafts file without affecting the SHA1 of HEAD. \nIn other words, given a commit SHA1 sum, you can be sure that someone else \nwho checks out the same commit (and has no local modification to their grafts \nfile) will see exactly the same history as you do.\n\nTo a certain degree, this is actually \"safer\" than today's (out-of-tree) \nsolution, where one can change the grafts file _without_ affecting the \ncurrent HEAD (SHA1 sum), and thus will not see the same history as someone \nelse who checks out the same HEAD. This is of course _intended_ to a certain \ndegree by the current implementation, but can easily cause confusion if \npeople lose track of what's in their respective grafts files.\n\nOf course, this is both a blessing and a curse: Say, for example, we have \nthree commits:\n\n... --> A --> B --> C\n\nand commit B changes the (in-tree) grafts file. Now if I have HEAD @ A, I will \nsee a different history than if I have HEAD @ C. Worse: If one person has \nHEAD @ A, and another person has HEAD @ C, and neither is aware of the grafts \nfile change in B, there is _plenty_ of room for getting confused if the two \npersons start discussing the repo history. Note, however, that similar \nconfusement can be achieved today if one of the persons forgets having \nchanged his out-of-tree grafts file\n\n\nThe grafts file concept is very powerful, but can also be extremely confusing. \nAdding in-tree versioning of the grafts file will make it more powerful \n(since we can now easily share and update \"errata\" to the repo history), but \nit might also make things _orders_of_magnitude_ more confusing (as \ndemonstrated in the above example, although to be fair, similar confusement \ncan be had in today's out-of-tree solution). At some point things may become \nso confusing that we'd rather drop the feature instead.\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"57692","messageId":"Pine.LNX.4.64.0710311340500.4362@racer.site","threadId":"10203","inReplyTo":"200710311343.58414.johan@herland.net","subject":"Re: Recording merges after repo conversion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-31T13:43:17Z","receivedAt":"2007-10-31T13:43:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 31 Oct 2007, Johan Herland wrote:\n\n> On Wednesday 31 October 2007, Johannes Schindelin wrote:\n> \n> > On Wed, 31 Oct 2007, Peter Karlsson wrote:\n> > \n> > > Johannes Schindelin:\n> > > \n> > > > Why should it?  This would contradict the whole \"a commit sha1 \n> > > > hashes the commit, and by inference the _whole_ history\" \n> > > > principle.\n> > > \n> > > Does it?\n> > \n> > Yes!  Of course!  If what you want becomes possible, I could make an \n> > evil change in history long gone, and slip it by you.  You could not \n> > even see the history which changed.\n> \n> Well, technically, if the grafts file was part of the repo, you wouldn't \n> be able to change the (in-tree) grafts file without affecting the SHA1 \n> of HEAD. In other words, given a commit SHA1 sum, you can be sure that \n> someone else who checks out the same commit (and has no local \n> modification to their grafts file) will see exactly the same history as \n> you do.\n\nAll this does not change the fact that installing a graft and 'git gc \n--prune'ing gets rid of the old history.  D'oh.\n\nAutomatically installing grafts is wrong.\n\nCiao,\nDscho\n"},{"id":"57704","messageId":"200710311537.30384.johan@herland.net","threadId":"10203","inReplyTo":"Pine.LNX.4.64.0710311340500.4362@racer.site","subject":"Re: Recording merges after repo conversion","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-10-31T14:37:26Z","receivedAt":"2007-10-31T14:37:26Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 31 October 2007, Johannes Schindelin wrote:\n> On Wed, 31 Oct 2007, Johan Herland wrote:\n> > On Wednesday 31 October 2007, Johannes Schindelin wrote:\n> > > On Wed, 31 Oct 2007, Peter Karlsson wrote:\n> > > > Johannes Schindelin:\n> > > > > Why should it?  This would contradict the whole \"a commit sha1 \n> > > > > hashes the commit, and by inference the _whole_ history\" \n> > > > > principle.\n> > > > \n> > > > Does it?\n> > > \n> > > Yes!  Of course!  If what you want becomes possible, I could make an \n> > > evil change in history long gone, and slip it by you.  You could not \n> > > even see the history which changed.\n> > \n> > Well, technically, if the grafts file was part of the repo, you wouldn't \n> > be able to change the (in-tree) grafts file without affecting the SHA1 \n> > of HEAD. In other words, given a commit SHA1 sum, you can be sure that \n> > someone else who checks out the same commit (and has no local \n> > modification to their grafts file) will see exactly the same history as \n> > you do.\n> \n> All this does not change the fact that installing a graft and 'git gc \n> --prune'ing gets rid of the old history.  D'oh.\n\nSo will rebasing and --prune'ing, or pulling a rebased branch and --prune'ing. \nGit already gives you _plenty_ of different ropes to hang yourself with. The \nquestion is whether adding yet another one is worth it.\n\n> Automatically installing grafts is wrong.\n\nI tend to agree with you here, because the possibility for massive confusion \nis huge, but that doesn't deny the fact that, if used properly (and that's a \n_big_ 'if'), this is a very powerful feature.\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"57705","messageId":"Pine.LNX.4.64.0710311503120.4362@racer.site","threadId":"10203","inReplyTo":"200710311537.30384.johan@herland.net","subject":"Re: Recording merges after repo conversion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-31T15:03:59Z","receivedAt":"2007-10-31T15:03:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 31 Oct 2007, Johan Herland wrote:\n\n> On Wednesday 31 October 2007, Johannes Schindelin wrote:\n>\n> > All this does not change the fact that installing a graft and 'git gc \n> > --prune'ing gets rid of the old history.  D'oh.\n> \n> So will rebasing and --prune'ing, or pulling a rebased branch and \n> --prune'ing. Git already gives you _plenty_ of different ropes to hang \n> yourself with. The question is whether adding yet another one is worth \n> it.\n\nBut that is not the question here.  The question here is: are users \nallowed to hang _others_?  I say: no.\n\nCiao,\nDscho\n"},{"id":"57707","messageId":"200710311621.09845.johan@herland.net","threadId":"10203","inReplyTo":"Pine.LNX.4.64.0710311503120.4362@racer.site","subject":"Re: Recording merges after repo conversion","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-10-31T15:21:04Z","receivedAt":"2007-10-31T15:21:04Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 31 October 2007, Johannes Schindelin wrote:\n> On Wed, 31 Oct 2007, Johan Herland wrote:\n> > On Wednesday 31 October 2007, Johannes Schindelin wrote:\n> > > All this does not change the fact that installing a graft and 'git gc \n> > > --prune'ing gets rid of the old history.  D'oh.\n> > \n> > So will rebasing and --prune'ing, or pulling a rebased branch and \n> > --prune'ing. Git already gives you _plenty_ of different ropes to hang \n> > yourself with. The question is whether adding yet another one is worth \n> > it.\n> \n> But that is not the question here.  The question here is: are users \n> allowed to hang _others_?  I say: no.\n\nWell, to a certain degree (and depending on your level of paranoia), you're \nalways responsible for the code entering your own repo, and you could always \nset up a hook disallowing \".gitgrafts\" (or whatever it would be called) from \nentering your repo.\n\nBut taking this (and everything else that's been said) into account, I totally \nagree with you that adding this feature would open up a _massive_ can of \nworms.\n\n\nEOD\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"57711","messageId":"Pine.LNX.4.64.0710311553510.4362@racer.site","threadId":"10203","inReplyTo":"200710311621.09845.johan@herland.net","subject":"Re: Recording merges after repo conversion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-31T15:57:12Z","receivedAt":"2007-10-31T15:57:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 31 Oct 2007, Johan Herland wrote:\n\n> Well, to a certain degree (and depending on your level of paranoia), \n> you're always responsible for the code entering your own repo, and you \n> could always set up a hook disallowing \".gitgrafts\" (or whatever it \n> would be called) from entering your repo.\n\nYeah, right.  And you could also stay in an oxygen tent the whole time to \navoid being infected with some virus.\n\nSeriously, your proposal does not make any sense.  If you have to set up a \nhook to get the _sane_ behaviour, something is really wrong.  So I do not \nreally understand why you brought up this idea here and now.\n\nI understand that you wanted to end this discussion, but I could _not_ let \nyour statement stand uncorrected.\n\nCiao,\nDscho\n"},{"id":"57712","messageId":"alpine.LFD.0.999.0710310928490.3340@woody.linux-foundation.org","threadId":"10203","inReplyTo":"Pine.LNX.4.64.0710311553510.4362@racer.site","subject":"Re: Recording merges after repo conversion","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-31T16:43:29Z","receivedAt":"2007-10-31T16:43:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 31 Oct 2007, Johannes Schindelin wrote:\n> \n> Seriously, your proposal does not make any sense.  If you have to set up a \n> hook to get the _sane_ behaviour, something is really wrong.  So I do not \n> really understand why you brought up this idea here and now.\n\nWell, I think this does kind of have some commonality with another issue \nthat has come up before: git clone only clones the really core repository \ndata.\n\nThat's generally a big feature, and I think it's absolutely the correct \nthing to do.\n\nBut I can also see that sometimes, you might want to clone more than the \nactual repository, and get things like SVN metadata, branch reflogs, \nvarious hooks and all the config options too.\n\nOf course, in practice, at least right now, the right thing to do for that \nis to just do a recursive filesystem copy and then a \"git status\", but I \nthink the background here is that some people simply do end up wanting to \ntransfer more infrastructure than just the actual repository data.\n\nOne thing to note: one reason for *not* allowing that is that incremental \nupgrades of non-repo data is obviously not possible. You might be able to \n*clone* a repo with config info and other metadata (if nothing else, then \nby just doing that raw filesystem copy), but you will never ever be able \nto _fetch_ the updates, because they aren't part of the core repository, \nand aren't versioned.\n\nSo I think I can understand why some people would want to do things like \nthis, but I do think it's broken. Yes, you can make the grafts file (or \nthe config file) be part of the repo, and even just add a symlink to your \n.git/ directory, but it's simply not a very good model.\n\nSo I think it always does end up breaking (other people might rebase, and \nbreak your grafts, or just not want them in the first place, or they don't \ncare about the same things, and mess up \"your\" configuration etc etc). So \nthe git repo layout is designed to have the minimally required shared \nstate, and not anything else.\n\n\t\tLinus\n"},{"id":"57714","messageId":"200710311808.55630.johan@herland.net","threadId":"10203","inReplyTo":"alpine.LFD.0.999.0710310928490.3340@woody.linux-foundation.org","subject":"Re: Recording merges after repo conversion","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-10-31T17:08:49Z","receivedAt":"2007-10-31T17:08:49Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 31 October 2007, Linus Torvalds wrote:\n> On Wed, 31 Oct 2007, Johannes Schindelin wrote:\n> > Seriously, your proposal does not make any sense.  If you have to set up a \n> > hook to get the _sane_ behaviour, something is really wrong.  So I do not \n> > really understand why you brought up this idea here and now.\n> \n> Well, I think this does kind of have some commonality with another issue \n> that has come up before: git clone only clones the really core repository \n> data.\n> \n> That's generally a big feature, and I think it's absolutely the correct \n> thing to do.\n> \n> But I can also see that sometimes, you might want to clone more than the \n> actual repository, and get things like SVN metadata, branch reflogs, \n> various hooks and all the config options too.\n> \n> Of course, in practice, at least right now, the right thing to do for that \n> is to just do a recursive filesystem copy and then a \"git status\", but I \n> think the background here is that some people simply do end up wanting to \n> transfer more infrastructure than just the actual repository data.\n> \n> One thing to note: one reason for *not* allowing that is that incremental \n> upgrades of non-repo data is obviously not possible. You might be able to \n> *clone* a repo with config info and other metadata (if nothing else, then \n> by just doing that raw filesystem copy), but you will never ever be able \n> to _fetch_ the updates, because they aren't part of the core repository, \n> and aren't versioned.\n> \n> So I think I can understand why some people would want to do things like \n> this, but I do think it's broken. Yes, you can make the grafts file (or \n> the config file) be part of the repo, and even just add a symlink to your \n> .git/ directory, but it's simply not a very good model.\n> \n> So I think it always does end up breaking (other people might rebase, and \n> break your grafts, or just not want them in the first place, or they don't \n> care about the same things, and mess up \"your\" configuration etc etc). So \n> the git repo layout is designed to have the minimally required shared \n> state, and not anything else.\n\nI agree that sharing the \"metainfo\" (i.e. config, grafts, hooks, reflogs, \nrerere magic, etc.) of the repo is not something git should do in the general \ncase.\n\nBut in some specific workflows (e.g. in-house, centralized workflows), I think \nit makes sense to coordinate/share some of this info between repos. But in \nthat case, I guess such coordination/sharing can be done by special-purpose \ntools built on top of git (e.g. in-house admin scripts).\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"}]}