{"thread":{"id":"14071","subject":"avoiding committing personal cruft","startedAt":"2008-06-21T13:20:06Z","lastAt":"2008-06-22T07:58:13Z","messageCount":3,"participants":["James Sadler","David"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"80547","messageId":"e5e204700806210620m35fce27eh8eddaf7cb68f1986@mail.gmail.com","threadId":"14071","inReplyTo":null,"subject":"avoiding committing personal cruft","fromName":"James Sadler","fromEmail":"freshtonic@gmail.com","sentAt":"2008-06-21T13:20:06Z","receivedAt":"2008-06-21T13:20:06Z","isPatch":false,"sender":{"key":"freshtonic@gmail.com","avatar":"https://gravatar.com/avatar/b6650ce4e0ec8d7169a964ef15255a74205599a33a9cb8295a6018db566c2fdc?d=mp&s=160"},"body":"I couldn't think of a better subject, so bear with me while I explain.\n\nLet's say I am contributing to some upstream project, and I am hacking on it\ninside my local repo's master branch. Let's also say that I enjoy\nusing my favourite IDE\nwhich creates its own project files and whatnot, and I don't want to\ncommit that stuff with the\nrest of the project code. It has no place being accidentally\npushed/pulled upstream. It's\nmy personal cruft, hence the subject line.\n\nHowever, I *do* want to version control my personal cruft, and I can\ndo that on a separate\nbranch. But I want the content of that other branch to exist in the\nworking tree alongside my\ncheckout of master.\n\nMy current solution basically involves versioning the IDE files on\nanother branch (named ide-branch),\nand using 'git checkout ide-branch .' to overlay the files on top of\nthe currently checked-out branch (master).\n\nThe ide-branch has nothing in it except the cruft from the IDE and the\npaths leading up to that cruft.\nThe master branch has a .gitignore that ignores the IDE files so I\nwon't end up polluting master by accident.\n\nIt's a manageable solution for now. I tend to think of it\nconceptually as 'layering' two branches: I want the\ncontent of both present in the working tree.\n\nI was just wondering if anyone else has tried something similar.\n\n\n James.\n\n\n\n-- \nCalvin Coolidge - \"I have never been hurt by what I have not said.\"\n"},{"id":"80551","messageId":"18c1e6480806210853k72274173gaaeb11dd7991c8ed@mail.gmail.com","threadId":"14071","inReplyTo":"e5e204700806210620m35fce27eh8eddaf7cb68f1986@mail.gmail.com","subject":"Re: avoiding committing personal cruft","fromName":"David","fromEmail":"wizzardx@gmail.com","sentAt":"2008-06-21T15:53:13Z","receivedAt":"2008-06-21T15:53:13Z","isPatch":false,"sender":{"key":"wizzardx@gmail.com","avatar":"https://gravatar.com/avatar/045483b90f748c2423d8321911ea9034f83f124c3e9ddb25e96011e6d68b20fb?d=mp&s=160"},"body":"On Sat, Jun 21, 2008 at 3:20 PM, James Sadler wrote:\n>\n> The ide-branch has nothing in it except the cruft from the IDE and the\n> paths leading up to that cruft.\n> The master branch has a .gitignore that ignores the IDE files so I\n> won't end up polluting master by accident.\n>\n> It's a manageable solution for now. I tend to think of it\n> conceptually as 'layering' two branches: I want the\n> content of both present in the working tree.\n>\n> I was just wondering if anyone else has tried something similar.\n>\n\nSounds like a normal use of topic branches. Branches rebased against\nmaster, where you you keep changes you don't want to go into the main\nbranch at this time.\n\nDavid.\n"},{"id":"80592","messageId":"18c1e6480806220058u72b1cbc5x9ec737c724258608@mail.gmail.com","threadId":"14071","inReplyTo":"e5e204700806211901v17a0450fw56b9db1c8c578dd@mail.gmail.com","subject":"Re: avoiding committing personal cruft","fromName":"David","fromEmail":"wizzardx@gmail.com","sentAt":"2008-06-22T07:58:13Z","receivedAt":"2008-06-22T07:58:13Z","isPatch":false,"sender":{"key":"wizzardx@gmail.com","avatar":"https://gravatar.com/avatar/045483b90f748c2423d8321911ea9034f83f124c3e9ddb25e96011e6d68b20fb?d=mp&s=160"},"body":"Re-cc-ing the list, I assume you didn't intend to mail me off-list.\n\nOn Sun, Jun 22, 2008 at 4:01 AM, James Sadler wrote:\n> 2008/6/22 David :\n>> On Sat, Jun 21, 2008 at 3:20 PM, James Sadler wrote:\n>>>\n>>> The ide-branch has nothing in it except the cruft from the IDE and the\n>>> paths leading up to that cruft.\n>>> The master branch has a .gitignore that ignores the IDE files so I\n>>> won't end up polluting master by accident.\n>>>\n>>> It's a manageable solution for now. I tend to think of it\n>>> conceptually as 'layering' two branches: I want the\n>>> content of both present in the working tree.\n>>>\n>>> I was just wondering if anyone else has tried something similar.\n>>>\n>>\n>> Sounds like a normal use of topic branches. Branches rebased against\n>> master, where you you keep changes you don't want to go into the main\n>> branch at this time.\n>\n> Just to clarify, are you saying that the topic branch would contain\n> all of master + ide cruft?\n> I was maintaining a branch that *only* contained my ide cruft.\n>\n\nMore correctly, the topic branch would contain the changes to the\nmaster branch required to add your personal cruft.\n\nHere is one relatively simple way to do it (there are other ways, this\none works well for me when I have local cruft I want for local dev but\ndon't want in public repos):\n\nAssuming you have these 2 branches:\n\nmaster - clean & version, ready to be used by others)\n\njames_updates - your own private cruft. work in progress, ide files,\netc, on top of the master branch. Not ready for others yet.\n\nDo all your hacking, private commits, cruft updates, etc in the\njames_updates branch. Also try to keep changes in separate commits (1\nfor cruft & personal files, 1 for feature change X, one for bugfix Y,\netc).\n\nLater, when you are ready to move (some of the) changes over to the\nmaster branch:\n\n1) Make a temporary copy of the james_updates branch:\n\ngit checkout james_updates\ngit checkout -b james_updates_tmp\n\n2) Interactively rebase the temporary branch over to master:\n\ngit rebase -i master\n\nDuring the interactive rebase, you strip out the cruft commits,\nreorder updates, etc, as necessary\n\n3) After the rebase, test the new version. Make sure it compiles and\nthe new features work correctly. Run any automated tests.\n\n4) Merge the temporary branch into master, and drop the temporary branch:\n\ngit checkout master\ngit merge james_updates_tmp\ngit branch -d james_updates_tmp\n\n5) Rebase your (original) updates branch onto the updated master:\n\ngit checkout james_updates\ngit rebase master\n\nNow you have a james_updates branch on top of master which only has\nyour cruft etc which you didn't merge earlier. The already-merged\ncommits are automatically removed from james_updates during the\nrebase.\n\nDavid.\n"}]}