{"thread":{"id":"363","subject":"Git fork removal?","startedAt":"2005-04-28T01:31:18Z","lastAt":"2005-04-28T15:29:47Z","messageCount":5,"participants":["Daniel Barkalow","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"1966","messageId":"Pine.LNX.4.21.0504272127400.30848-100000@iabervon.org","threadId":"363","inReplyTo":null,"subject":"Git fork removal?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-28T01:31:18Z","receivedAt":"2005-04-28T01:31:18Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"I saw that \"fork\" was removed when going to the cg- scripts, and the\nreplacements don't do the symlinked trees thing. I found the symlinked\ntrees thing vital to my workflow, so I'm going to want to reintroduce\nthem, or something similar. Is there some reason you went to hardlinked\nobject files instead of symlinked directories?\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"1975","messageId":"20050428021237.GA8612@pasky.ji.cz","threadId":"363","inReplyTo":"Pine.LNX.4.21.0504272127400.30848-100000@iabervon.org","subject":"Re: Git fork removal?","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-28T02:12:37Z","receivedAt":"2005-04-28T02:12:37Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Apr 28, 2005 at 03:31:18AM CEST, I got a letter\nwhere Daniel Barkalow told me that...\n> I saw that \"fork\" was removed when going to the cg- scripts, and the\n> replacements don't do the symlinked trees thing. I found the symlinked\n> trees thing vital to my workflow, so I'm going to want to reintroduce\n> them, or something similar. Is there some reason you went to hardlinked\n> object files instead of symlinked directories?\n\nThe user. ;-)\n\nApparently, too many people were confused by the local/remote branches\ndistinctions, and even I ceased to like it gradually (BTW, Cogito still\nsupports working with them - it just does not offer any interface for\nmanipulation with them). The current scheme is much simpler and I\nbelieve more clear.\n\nAlso, the forked repositories were not truly independent - people\nactually got burnt by forking and then removing the original repository.\n\nIf this breaks your workflow, could you please describe it? Perhaps we\ncould find a good semantics to support both.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"1982","messageId":"Pine.LNX.4.21.0504272221030.30848-100000@iabervon.org","threadId":"363","inReplyTo":"20050428021237.GA8612@pasky.ji.cz","subject":"Re: Git fork removal?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-28T02:47:24Z","receivedAt":"2005-04-28T02:47:24Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 28 Apr 2005, Petr Baudis wrote:\n\n> Dear diary, on Thu, Apr 28, 2005 at 03:31:18AM CEST, I got a letter\n> where Daniel Barkalow told me that...\n> > I saw that \"fork\" was removed when going to the cg- scripts, and the\n> > replacements don't do the symlinked trees thing. I found the symlinked\n> > trees thing vital to my workflow, so I'm going to want to reintroduce\n> > them, or something similar. Is there some reason you went to hardlinked\n> > object files instead of symlinked directories?\n> \n> The user. ;-)\n> \n> Apparently, too many people were confused by the local/remote branches\n> distinctions, and even I ceased to like it gradually (BTW, Cogito still\n> supports working with them - it just does not offer any interface for\n> manipulation with them). The current scheme is much simpler and I\n> believe more clear.\n\nI don't really like having local branches and remote repositories be\ntreated the same. But I like each of them being available concepts\nseparately.\n\n> Also, the forked repositories were not truly independent - people\n> actually got burnt by forking and then removing the original repository.\n\nAh, okay. I'm actually personally using a original repository called\n\"REPOSITORY\" without a head or anything, with symlinks to that, so I don't\nworry about accidentally killing the real thing from some branch. I've\nreally got a storage area per project, plus a set of links and tracking\nstuff for each fork. I also back up the REPOSITORY on occasion,\nparticularly if I'm about to do something potentially destructive to the\ndatabase (like git-prune-script or convert-cache). I structure my\nfilesystem like:\n\n /working\n ... other projects\n /git\n /REPOSITORY (with only .git, non-symlink version)\n /linus\n /pasky\n /barkalow\n /cog-barkalow\n /diff\n ...\n\n> If this breaks your workflow, could you please describe it? Perhaps we\n> could find a good semantics to support both.\n\nThe part that I'm worried about is the way I turn a mass of debugging and\nlittle local commits into a clean patch series. I've got a working fork\n\"barkalow\", which is the result of a bunch of stuff and a dozen\ncommits. It is derived from \"linus\". I want to split up the changes and\nmake a series of commits, each of which will be a patch to submit.\n\n1) I fork \"linus\" into \"for-linus\". I go into \"for-linus\".\n\n2) I do \"git diff this:barkalow > patch\". This gives me the complete set\n of changes I want to submit.\n\n3) I cut down the diff to a single logical change by removing all of the\n other hunks.\n\n4) I do \"git apply < patch\". I do \"git commit\". I describe the logical\n change.\n\n5) I go back to step 2, unless I'm done.\n\n6) For each of the commits between \"linus\" and \"for-linus\", I do \n \"git patch \", and send out the result.\n\nThe thing that I think requires the symlinks is step 2, which requires\nthat there be somewhere I can run git and have it able to see a pair of\nunrelated local heads and the relevant trees.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"2020","messageId":"20050428091039.GI8612@pasky.ji.cz","threadId":"363","inReplyTo":"Pine.LNX.4.21.0504272221030.30848-100000@iabervon.org","subject":"Re: Git fork removal?","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-28T09:10:39Z","receivedAt":"2005-04-28T09:10:39Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Apr 28, 2005 at 04:47:24AM CEST, I got a letter\nwhere Daniel Barkalow told me that...\n> > If this breaks your workflow, could you please describe it? Perhaps we\n> > could find a good semantics to support both.\n> \n> The part that I'm worried about is the way I turn a mass of debugging and\n> little local commits into a clean patch series. I've got a working fork\n> \"barkalow\", which is the result of a bunch of stuff and a dozen\n> commits. It is derived from \"linus\". I want to split up the changes and\n> make a series of commits, each of which will be a patch to submit.\n> \n> 1) I fork \"linus\" into \"for-linus\". I go into \"for-linus\".\n> \n> 2) I do \"git diff this:barkalow > patch\". This gives me the complete set\n> of changes I want to submit.\n> \n> 3) I cut down the diff to a single logical change by removing all of the\n> other hunks.\n> \n> 4) I do \"git apply < patch\". I do \"git commit\". I describe the logical\n> change.\n> \n> 5) I go back to step 2, unless I'm done.\n> \n> 6) For each of the commits between \"linus\" and \"for-linus\", I do \n> \"git patch \", and send out the result.\n> \n> The thing that I think requires the symlinks is step 2, which requires\n> that there be somewhere I can run git and have it able to see a pair of\n> unrelated local heads and the relevant trees.\n\nJust do cg-pull barkalow, to get the latest changes from that repository\n(perhaps clone should inherit branches information?).\n\nBut if you want Linus to pull from your tree, you generally want it to\nbe clean - that is, you want to manage clean separation (as Pavel Machek\ndescribes in his document). That is another advantage of hardlinking -\nyou don't get any unrelated stuff in if you don't explicitly pull it, so\nyou can keep your for-linus branch clean. I'd do cg-diff linus:this in\nthe barkalow branch instead to keep this property.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"2042","messageId":"Pine.LNX.4.21.0504281115210.30848-100000@iabervon.org","threadId":"363","inReplyTo":"20050428091039.GI8612@pasky.ji.cz","subject":"Re: Git fork removal?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-28T15:29:47Z","receivedAt":"2005-04-28T15:29:47Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 28 Apr 2005, Petr Baudis wrote:\n\n> Dear diary, on Thu, Apr 28, 2005 at 04:47:24AM CEST, I got a letter\n> where Daniel Barkalow told me that...\n>\n> > The thing that I think requires the symlinks is step 2, which requires\n> > that there be somewhere I can run git and have it able to see a pair of\n> > unrelated local heads and the relevant trees.\n> \n> Just do cg-pull barkalow, to get the latest changes from that repository\n> (perhaps clone should inherit branches information?).\n\nYou can pull from local repositories? I think that having the same concept\nfor remote repositories and for different lines of local development is\nwhat confuses users.\n\n> But if you want Linus to pull from your tree, you generally want it to\n> be clean - that is, you want to manage clean separation (as Pavel Machek\n> describes in his document).\n\nI'll be using rpush and he'd have to use http-pull (I don't have rsync\nset up); both of these only transfer the reachable objects, so cleanliness\nisn't an issue.\n\n> That is another advantage of hardlinking -\n> you don't get any unrelated stuff in if you don't explicitly pull it, so\n> you can keep your for-linus branch clean. I'd do cg-diff linus:this in\n> the barkalow branch instead to keep this property.\n\nBut that doesn't work; when I'm preparing the second patch in the series,\nI want to compare linus+patch 1 against barkalow, so that I'm looking at\nwhat's left to split. That's why I need to have the unrelated heads, not\njust the linus head and my head based on it. If I go back to linus each\ntime, it's more work making the patches and I don't have an easy way of\ntelling whether I've included the same part twice or missed a part.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"}]}