{"thread":{"id":"16726","subject":"How to maintain private/secret/confidential branch.","startedAt":"2008-12-14T13:49:50Z","lastAt":"2008-12-18T08:03:48Z","messageCount":11,"participants":["Łukasz Lew","Nick Andrew","Alexander Potashev","Sitaram Chamarty","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"97878","messageId":"c55009e70812140549t6547c1d6jf7780f91b5074e73@mail.gmail.com","threadId":"16726","inReplyTo":null,"subject":"How to maintain private/secret/confidential branch.","fromName":"Łukasz Lew","fromEmail":"lukasz.lew@gmail.com","sentAt":"2008-12-14T13:49:50Z","receivedAt":"2008-12-14T13:49:50Z","isPatch":false,"sender":{"key":"lukasz.lew@gmail.com","avatar":"https://gravatar.com/avatar/824c7ecf4e2ee1e37a2e3b7dd58d4a745cb68855f58d06a5cb861b0b42531dea?d=mp&s=160"},"body":"Hi,\n\nI don't know how to make such a scenario work:\n- two repositories: pub, priv\n- priv is clone/branch of pub\n- there is some constant developement both in pub and priv\n- there are regular syncs with pub in priv\n\nProblem:\nOccasionally I want to push some changes from priv to pub.\nThen after syncing with pub I want to get as few conflicts as possible.\n\nIs it possible to do with git?\n\nThanks\nLukasz\n"},{"id":"97880","messageId":"20081214145518.GA26380@mail.local.tull.net","threadId":"16726","inReplyTo":"c55009e70812140549t6547c1d6jf7780f91b5074e73@mail.gmail.com","subject":"Re: How to maintain private/secret/confidential branch.","fromName":"Nick Andrew","fromEmail":"nick@nick-andrew.net","sentAt":"2008-12-14T14:55:18Z","receivedAt":"2008-12-14T14:55:18Z","isPatch":false,"sender":{"key":"nick@nick-andrew.net","avatar":"https://gravatar.com/avatar/85f25a67ca6eaa4016ed374f6d07f3cd853c886aeb7e1507eb7dbc47b00082fe?d=mp&s=160"},"body":"On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:\n> I don't know how to make such a scenario work:\n> - two repositories: pub, priv\n> - priv is clone/branch of pub\n> - there is some constant developement both in pub and priv\n> - there are regular syncs with pub in priv\n> \n> Problem:\n> Occasionally I want to push some changes from priv to pub.\n> Then after syncing with pub I want to get as few conflicts as possible.\n> \n> Is it possible to do with git?\n\nGit can do almost anything. One should instead ask \"How to do this\nwith git?\" :-)\n\nIf I understand your problem, you could solve it with git cherry-pick\nand rebase. On priv, make a for-public branch from a pub branch. Then\ncherry-pick the commits you want from your private branch into the\nfor-public branch. Push your for-public branch to pub, then rebase\nyour private branch.\n\nNick.\n"},{"id":"97881","messageId":"c55009e70812140738l8b51adax77cc6e507971554e@mail.gmail.com","threadId":"16726","inReplyTo":"20081214145518.GA26380@mail.local.tull.net","subject":"Re: How to maintain private/secret/confidential branch.","fromName":"Łukasz Lew","fromEmail":"lukasz.lew@gmail.com","sentAt":"2008-12-14T15:38:35Z","receivedAt":"2008-12-14T15:38:35Z","isPatch":false,"sender":{"key":"lukasz.lew@gmail.com","avatar":"https://gravatar.com/avatar/824c7ecf4e2ee1e37a2e3b7dd58d4a745cb68855f58d06a5cb861b0b42531dea?d=mp&s=160"},"body":"Thanks Nick, thats really helpful (and surprisingly simple).\nI have a couple more questions:\n\nOn Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:\n> On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:\n>> I don't know how to make such a scenario work:\n>> - two repositories: pub, priv\n>> - priv is clone/branch of pub\n>> - there is some constant developement both in pub and priv\n>> - there are regular syncs with pub in priv\n>>\n>> Problem:\n>> Occasionally I want to push some changes from priv to pub.\n>> Then after syncing with pub I want to get as few conflicts as possible.\n>>\n>> Is it possible to do with git?\n>\n> Git can do almost anything. One should instead ask \"How to do this\n> with git?\" :-)\n\nSo I've heard, but not yet experienced it myself. I'm thrilled to try.\n\n>\n> If I understand your problem, you could solve it with git cherry-pick\n> and rebase. On priv, make a for-public branch from a pub branch. Then\n> cherry-pick the commits you want from your private branch into the\n> for-public branch.\n\nThat almost works. Can I somehow split existing commits just like in git-add -p?\n\n> Push your for-public branch to pub,\n> then rebase your private branch.\n\nRebase to the tip of master? Is it needed? Ie. cherry-pick does not\nremove the patch from\nthe master in priv.\n\nIf I now pull from pub, I will get the same change and it mereges nicely :D\n\nCan I get away without creating for_pub branch? maybe cherry pick in\npub from priv somehow?\n\n>\n> Nick.\n>\n"},{"id":"97882","messageId":"20081214160645.GA21358@myhost","threadId":"16726","inReplyTo":"c55009e70812140738l8b51adax77cc6e507971554e@mail.gmail.com","subject":"Re: How to maintain private/secret/confidential branch.","fromName":"Alexander Potashev","fromEmail":"aspotashev@gmail.com","sentAt":"2008-12-14T16:06:45Z","receivedAt":"2008-12-14T16:06:45Z","isPatch":false,"sender":{"key":"aspotashev@gmail.com","avatar":null},"body":"Hello, Łukasz!\n\nOn 16:38 Sun 14 Dec     , Łukasz Lew wrote:\n> Thanks Nick, thats really helpful (and surprisingly simple).\n> I have a couple more questions:\n> \n> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:\n> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:\n> >> I don't know how to make such a scenario work:\n> >> - two repositories: pub, priv\n> >> - priv is clone/branch of pub\n> >> - there is some constant developement both in pub and priv\n> >> - there are regular syncs with pub in priv\n> >>\n> >> Problem:\n> >> Occasionally I want to push some changes from priv to pub.\n> >> Then after syncing with pub I want to get as few conflicts as possible.\n> >>\n> >> Is it possible to do with git?\n> >\n> > Git can do almost anything. One should instead ask \"How to do this\n> > with git?\" :-)\n> \n> So I've heard, but not yet experienced it myself. I'm thrilled to try.\n> \n> >\n> > If I understand your problem, you could solve it with git cherry-pick\n> > and rebase. On priv, make a for-public branch from a pub branch. Then\n> > cherry-pick the commits you want from your private branch into the\n> > for-public branch.\n> \n> That almost works. Can I somehow split existing commits just like in git-add -p?\nIt's, however, better to make more commits to not experience the need of\ncommit splitting.\n\nBut you can use '--no-commit' option of 'git cherry-pick' and 'git merge'\n(and 'git pull' as well as 'git merge'). For example:\n\n\tgit cherry-pick --no-commit <sha1>    # cherry-pick without commiting\n\tgit reset --                          # unstage all changes\n\tgit add -p                            # patch update\n\nYou can also use 'git add -i' (interative mode) instead of 'git add -p'.\n\n> \n> > Push your for-public branch to pub,\n> > then rebase your private branch.\n> \n> Rebase to the tip of master? Is it needed? Ie. cherry-pick does not\n> remove the patch from\n> the master in priv.\n> \n> If I now pull from pub, I will get the same change and it mereges nicely :D\n> \n> Can I get away without creating for_pub branch? maybe cherry pick in\n> pub from priv somehow?\n> \n> >\n> > Nick.\n> >\n\n\t\t\t\t\tAlexander\n"},{"id":"97884","messageId":"gi3bap$asc$1@ger.gmane.org","threadId":"16726","inReplyTo":"c55009e70812140738l8b51adax77cc6e507971554e@mail.gmail.com","subject":"Re: How to maintain private/secret/confidential branch.","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2008-12-14T16:13:13Z","receivedAt":"2008-12-14T16:13:13Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2008-12-14, Łukasz Lew <lukasz.lew@gmail.com> wrote:\n> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:\n>> If I understand your problem, you could solve it with git cherry-pick\n>> and rebase. On priv, make a for-public branch from a pub branch. Then\n>> cherry-pick the commits you want from your private branch into the\n>> for-public branch.\n>\n> That almost works. Can I somehow split existing commits\n> just like in git-add -p?\n\nThis is going to sound weird to some seasoned folks, and I'm\nhoping to hear better ways of doing this.  But having done\nstuff like this, I once wrote it up and here're my notes:\n\nTo split just the top commit into multiple commits:\n    * start git gui\n    * choose \"amend last commit\" from the commit menu\n    * unstage all files (meaning you click on the little\n      icons so they move from the left-bottom panel to the\n      left-top panel)\n    * pick files or hunks in files to stage and commit the\n      usual way\n    * continue all changes are committed\n\nTo split a commit that is *not* the top one:\n    * start an interactive rebase that includes that commit\n    * mark that commit as \"edit\" and start the rebase\n    * when the rebase pauses, use git gui as described above\n\nTo combine a set of commits and split the result in some\nother way (meaning you have commits A B P Q C D R E S and you\nwant to make them A B C D X Y Z where X+Y+Z = P+Q+R+S!)\n    * start an interactive rebase\n    * move lines as appropriate (in the editor) so the\n      commits P,Q,R,S are together\n    * choose \"squash\" on the second and subsequent ones and\n      start the rebase\n    * (dirty trick warning) when the editor for the combined\n      commit message pops up, delete ALL the lines and save\n    * use git gui as above\n    * then continue the rebase\n\nHope this helps...\n"},{"id":"97887","messageId":"c55009e70812140848j79202b0aqc6ffbfecfff50757@mail.gmail.com","threadId":"16726","inReplyTo":"20081214160645.GA21358@myhost","subject":"Re: How to maintain private/secret/confidential branch.","fromName":"Łukasz Lew","fromEmail":"lukasz.lew@gmail.com","sentAt":"2008-12-14T16:48:30Z","receivedAt":"2008-12-14T16:48:30Z","isPatch":false,"sender":{"key":"lukasz.lew@gmail.com","avatar":"https://gravatar.com/avatar/824c7ecf4e2ee1e37a2e3b7dd58d4a745cb68855f58d06a5cb861b0b42531dea?d=mp&s=160"},"body":"Hi Alexander,\n\nOn Sun, Dec 14, 2008 at 17:06, Alexander Potashev <aspotashev@gmail.com> wrote:\n> Hello, Łukasz!\n>\n> On 16:38 Sun 14 Dec     , Łukasz Lew wrote:\n>> Thanks Nick, thats really helpful (and surprisingly simple).\n>> I have a couple more questions:\n>>\n>> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:\n>> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:\n>> >> I don't know how to make such a scenario work:\n>> >> - two repositories: pub, priv\n>> >> - priv is clone/branch of pub\n>> >> - there is some constant developement both in pub and priv\n>> >> - there are regular syncs with pub in priv\n>> >>\n>> >> Problem:\n>> >> Occasionally I want to push some changes from priv to pub.\n>> >> Then after syncing with pub I want to get as few conflicts as possible.\n>> >>\n>> >> Is it possible to do with git?\n>> >\n>> > Git can do almost anything. One should instead ask \"How to do this\n>> > with git?\" :-)\n>>\n>> So I've heard, but not yet experienced it myself. I'm thrilled to try.\n>>\n>> >\n>> > If I understand your problem, you could solve it with git cherry-pick\n>> > and rebase. On priv, make a for-public branch from a pub branch. Then\n>> > cherry-pick the commits you want from your private branch into the\n>> > for-public branch.\n>>\n>> That almost works. Can I somehow split existing commits just like in git-add -p?\n> It's, however, better to make more commits to not experience the need of\n> commit splitting.\n\nIndeed good advice and best practice, but another best practice is to\nnot commit not compiling state.\nMy common scenario is that I code a big change in priv repository, and\nafter that I find that some of its parts can and should be moved to\npub.\n\n>\n> But you can use '--no-commit' option of 'git cherry-pick' and 'git merge'\n> (and 'git pull' as well as 'git merge'). For example:\n>\n>        git cherry-pick --no-commit <sha1>    # cherry-pick without commiting\n>        git reset --                          # unstage all changes\n>        git add -p                            # patch update\n>\n> You can also use 'git add -i' (interative mode) instead of 'git add -p'.\n\nThat's a possible solution indeed.\nNow I see that the right \"plumbing\" I need is splitting a commit into\nsmaller parts and merging several commits into a larger one.\n\nI think that would be nice functionality.\n\nDo you know any tool that would allow such a manipulation on commits\nin history?\n\nThanks\nLukasz\n\n>\n>>\n>> > Push your for-public branch to pub,\n>> > then rebase your private branch.\n>>\n>> Rebase to the tip of master? Is it needed? Ie. cherry-pick does not\n>> remove the patch from\n>> the master in priv.\n>>\n>> If I now pull from pub, I will get the same change and it mereges nicely :D\n>>\n>> Can I get away without creating for_pub branch? maybe cherry pick in\n>> pub from priv somehow?\n>>\n>> >\n>> > Nick.\n>> >\n>\n>                                        Alexander\n>\n"},{"id":"97999","messageId":"alpine.LNX.1.00.0812151501570.19665@iabervon.org","threadId":"16726","inReplyTo":"c55009e70812140848j79202b0aqc6ffbfecfff50757@mail.gmail.com","subject":"Re: How to maintain private/secret/confidential branch.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-12-15T20:31:14Z","receivedAt":"2008-12-15T20:31:14Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 14 Dec 2008, Łukasz Lew wrote:\n\n> Hi Alexander,\n> \n> On Sun, Dec 14, 2008 at 17:06, Alexander Potashev <aspotashev@gmail.com> wrote:\n> > Hello, Łukasz!\n> >\n> > On 16:38 Sun 14 Dec     , Łukasz Lew wrote:\n> >> Thanks Nick, thats really helpful (and surprisingly simple).\n> >> I have a couple more questions:\n> >>\n> >> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:\n> >> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:\n> >> >> I don't know how to make such a scenario work:\n> >> >> - two repositories: pub, priv\n> >> >> - priv is clone/branch of pub\n> >> >> - there is some constant developement both in pub and priv\n> >> >> - there are regular syncs with pub in priv\n> >> >>\n> >> >> Problem:\n> >> >> Occasionally I want to push some changes from priv to pub.\n> >> >> Then after syncing with pub I want to get as few conflicts as possible.\n> >> >>\n> >> >> Is it possible to do with git?\n> >> >\n> >> > Git can do almost anything. One should instead ask \"How to do this\n> >> > with git?\" :-)\n> >>\n> >> So I've heard, but not yet experienced it myself. I'm thrilled to try.\n> >>\n> >> >\n> >> > If I understand your problem, you could solve it with git cherry-pick\n> >> > and rebase. On priv, make a for-public branch from a pub branch. Then\n> >> > cherry-pick the commits you want from your private branch into the\n> >> > for-public branch.\n> >>\n> >> That almost works. Can I somehow split existing commits just like in git-add -p?\n> > It's, however, better to make more commits to not experience the need of\n> > commit splitting.\n> \n> Indeed good advice and best practice, but another best practice is to\n> not commit not compiling state.\n\nIn your private branches, it's actually good practice to commit all sorts \nof junk. That way, when you mess up badly while trying to get it to \ncompile, you won't have lost your work. Of course, that means your commits \nare going to need more cleanup before going public.\n\n> My common scenario is that I code a big change in priv repository, and\n> after that I find that some of its parts can and should be moved to\n> pub.\n\nI usually end up with my private branch containing the public branch, plus \na bunch of commits that introduce: bugs, later fixed; mixed improvements; \nand debugging cruft. I want to generate nice commits that are individual \nimprovements. I generally do:\n$ git checkout -b submit origin/master (the first time, to set it up)\n\n$ git checkout submit \n$ git diff submit mixed-work\nlook at it for good changes, find some in file1 and file2\n$ git diff submit mixed-work -- file1 file2 | git apply\nSometimes, clean up bits that aren't ideal\n$ git add -i\nAdd the good parts\n$ git checkout . (revert the working tree to the index)\n$ make test (did I extract the change correctly?)\n$ git commit\nWrite a good message, sign off, etc\n$ git checkout mixed-work\n$ git rebase -i submit\nOften, resolve easy conflicts where my mixed-work branch introduced bugs \nthat I fixed later and have now adopted the fixed code\n\nThen I repeat until I don't have any more good changes in mixed-work \n(either I have nothing, only debugging cruft, or only stuff I haven't \ngotten to work yet). If there's nothing but cruft, I've fully merged the \ntopic, and I delete the branch.\n\nEventually, I'm satisfied with what I've cleaned up, and I do:\n$ git push origin submit:master\n\nAlso, I generally have a bunch of \"mixed-work\" branches, each containing \ndifferent stuff that isn't ready. I'll periodicly go through all of them \nand rebase onto \"submit\" or \"origin/master\" (or, sometimes, give up on \nthem and delete them).\n\n(One thing that would be nice to have is a \"git apply --interactive\" which \napplies the user's choice of hunks, like \"git add -i\" adds them)\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"98170","messageId":"c55009e70812171157s7932c0b3u7a8ee6557c140d56@mail.gmail.com","threadId":"16726","inReplyTo":"alpine.LNX.1.00.0812151501570.19665@iabervon.org","subject":"Re: How to maintain private/secret/confidential branch.","fromName":"Łukasz Lew","fromEmail":"lukasz.lew@gmail.com","sentAt":"2008-12-17T19:57:35Z","receivedAt":"2008-12-17T19:57:35Z","isPatch":false,"sender":{"key":"lukasz.lew@gmail.com","avatar":"https://gravatar.com/avatar/824c7ecf4e2ee1e37a2e3b7dd58d4a745cb68855f58d06a5cb861b0b42531dea?d=mp&s=160"},"body":"Well, I am still a beginner in git. I just switched from mercurial.\nSome inline follows:\n\n2008/12/15 Daniel Barkalow <barkalow@iabervon.org>:\n> On Sun, 14 Dec 2008, Łukasz Lew wrote:\n>\n>> Hi Alexander,\n>>\n>> On Sun, Dec 14, 2008 at 17:06, Alexander Potashev <aspotashev@gmail.com> wrote:\n>> > Hello, Łukasz!\n>> >\n>> > On 16:38 Sun 14 Dec     , Łukasz Lew wrote:\n>> >> Thanks Nick, thats really helpful (and surprisingly simple).\n>> >> I have a couple more questions:\n>> >>\n>> >> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:\n>> >> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:\n>> >> >> I don't know how to make such a scenario work:\n>> >> >> - two repositories: pub, priv\n>> >> >> - priv is clone/branch of pub\n>> >> >> - there is some constant developement both in pub and priv\n>> >> >> - there are regular syncs with pub in priv\n>> >> >>\n>> >> >> Problem:\n>> >> >> Occasionally I want to push some changes from priv to pub.\n>> >> >> Then after syncing with pub I want to get as few conflicts as possible.\n>> >> >>\n>> >> >> Is it possible to do with git?\n>> >> >\n>> >> > Git can do almost anything. One should instead ask \"How to do this\n>> >> > with git?\" :-)\n>> >>\n>> >> So I've heard, but not yet experienced it myself. I'm thrilled to try.\n>> >>\n>> >> >\n>> >> > If I understand your problem, you could solve it with git cherry-pick\n>> >> > and rebase. On priv, make a for-public branch from a pub branch. Then\n>> >> > cherry-pick the commits you want from your private branch into the\n>> >> > for-public branch.\n>> >>\n>> >> That almost works. Can I somehow split existing commits just like in git-add -p?\n>> > It's, however, better to make more commits to not experience the need of\n>> > commit splitting.\n>>\n>> Indeed good advice and best practice, but another best practice is to\n>> not commit not compiling state.\n>\n> In your private branches, it's actually good practice to commit all sorts\n> of junk. That way, when you mess up badly while trying to get it to\n> compile, you won't have lost your work. Of course, that means your commits\n> are going to need more cleanup before going public.\n\nI started to follow your advise.\nThen I rebase -i.\nI found out I need more precise commit messages. :)\n\n>\n>> My common scenario is that I code a big change in priv repository, and\n>> after that I find that some of its parts can and should be moved to\n>> pub.\n>\n> I usually end up with my private branch containing the public branch, plus\n> a bunch of commits that introduce: bugs, later fixed; mixed improvements;\n> and debugging cruft. I want to generate nice commits that are individual\n> improvements. I generally do:\n> $ git checkout -b submit origin/master (the first time, to set it up)\n>\n> $ git checkout submit\n> $ git diff submit mixed-work\n> look at it for good changes, find some in file1 and file2\n> $ git diff submit mixed-work -- file1 file2 | git apply\n\nBut with this command we do not preserve objects identity.\nI.e: when you merge with mixed-work you have duplicate changes.\nIs it ok?\n\n> Sometimes, clean up bits that aren't ideal\n> $ git add -i\n> Add the good parts\n> $ git checkout . (revert the working tree to the index)\n> $ make test (did I extract the change correctly?)\n> $ git commit\n> Write a good message, sign off, etc\n> $ git checkout mixed-work\n> $ git rebase -i submit\n\n... Ah I see, we throw away old commits anyway with rebasing.\n\n> Often, resolve easy conflicts where my mixed-work branch introduced bugs\n> that I fixed later and have now adopted the fixed code\n>\n> Then I repeat until I don't have any more good changes in mixed-work\n> (either I have nothing, only debugging cruft, or only stuff I haven't\n> gotten to work yet). If there's nothing but cruft, I've fully merged the\n> topic, and I delete the branch.\n>\n> Eventually, I'm satisfied with what I've cleaned up, and I do:\n> $ git push origin submit:master\n>\n> Also, I generally have a bunch of \"mixed-work\" branches, each containing\n> different stuff that isn't ready. I'll periodicly go through all of them\n> and rebase onto \"submit\" or \"origin/master\" (or, sometimes, give up on\n> them and delete them).\n>\n> (One thing that would be nice to have is a \"git apply --interactive\" which\n> applies the user's choice of hunks, like \"git add -i\" adds them)\n\nI totally agree.\n\nI would appriciate rebase --copy option, which doesn't move, but copy\nthe changelists like cherry-pick.\nThen we could use rebase -i (with edit) instead of apply.\n\nPS\nWhy after edit in rebase -i the change is already commited? I always\nhave to reset;add -i\n\n>\n>        -Daniel\n> *This .sig left intentionally blank*\n"},{"id":"98174","messageId":"alpine.LNX.1.00.0812171500070.19665@iabervon.org","threadId":"16726","inReplyTo":"c55009e70812171157s7932c0b3u7a8ee6557c140d56@mail.gmail.com","subject":"Re: How to maintain private/secret/confidential branch.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-12-17T20:27:04Z","receivedAt":"2008-12-17T20:27:04Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 17 Dec 2008, Łukasz Lew wrote:\n\n> Well, I am still a beginner in git. I just switched from mercurial.\n> Some inline follows:\n> \n> 2008/12/15 Daniel Barkalow <barkalow@iabervon.org>:\n> > On Sun, 14 Dec 2008, Łukasz Lew wrote:\n> >\n> >> Hi Alexander,\n> >>\n> >> On Sun, Dec 14, 2008 at 17:06, Alexander Potashev <aspotashev@gmail.com> wrote:\n> >> > Hello, Łukasz!\n> >> >\n> >> > On 16:38 Sun 14 Dec     , Łukasz Lew wrote:\n> >> >> Thanks Nick, thats really helpful (and surprisingly simple).\n> >> >> I have a couple more questions:\n> >> >>\n> >> >> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:\n> >> >> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:\n> >> >> >> I don't know how to make such a scenario work:\n> >> >> >> - two repositories: pub, priv\n> >> >> >> - priv is clone/branch of pub\n> >> >> >> - there is some constant developement both in pub and priv\n> >> >> >> - there are regular syncs with pub in priv\n> >> >> >>\n> >> >> >> Problem:\n> >> >> >> Occasionally I want to push some changes from priv to pub.\n> >> >> >> Then after syncing with pub I want to get as few conflicts as possible.\n> >> >> >>\n> >> >> >> Is it possible to do with git?\n> >> >> >\n> >> >> > Git can do almost anything. One should instead ask \"How to do this\n> >> >> > with git?\" :-)\n> >> >>\n> >> >> So I've heard, but not yet experienced it myself. I'm thrilled to try.\n> >> >>\n> >> >> >\n> >> >> > If I understand your problem, you could solve it with git cherry-pick\n> >> >> > and rebase. On priv, make a for-public branch from a pub branch. Then\n> >> >> > cherry-pick the commits you want from your private branch into the\n> >> >> > for-public branch.\n> >> >>\n> >> >> That almost works. Can I somehow split existing commits just like in git-add -p?\n> >> > It's, however, better to make more commits to not experience the need of\n> >> > commit splitting.\n> >>\n> >> Indeed good advice and best practice, but another best practice is to\n> >> not commit not compiling state.\n> >\n> > In your private branches, it's actually good practice to commit all sorts\n> > of junk. That way, when you mess up badly while trying to get it to\n> > compile, you won't have lost your work. Of course, that means your commits\n> > are going to need more cleanup before going public.\n> \n> I started to follow your advise.\n> Then I rebase -i.\n> I found out I need more precise commit messages. :)\n\nOne useful strategy is to have a second shell and do \"git show <hash>\" to \nfigure out what you did in that misc commit.\n\n> >> My common scenario is that I code a big change in priv repository, and\n> >> after that I find that some of its parts can and should be moved to\n> >> pub.\n> >\n> > I usually end up with my private branch containing the public branch, plus\n> > a bunch of commits that introduce: bugs, later fixed; mixed improvements;\n> > and debugging cruft. I want to generate nice commits that are individual\n> > improvements. I generally do:\n> > $ git checkout -b submit origin/master (the first time, to set it up)\n> >\n> > $ git checkout submit\n> > $ git diff submit mixed-work\n> > look at it for good changes, find some in file1 and file2\n> > $ git diff submit mixed-work -- file1 file2 | git apply\n> \n> But with this command we do not preserve objects identity.\n> I.e: when you merge with mixed-work you have duplicate changes.\n> Is it ok?\n\nGit is very good about recognizing duplicate changes in 3-way situations. \nThat is, merging two branches, each of which makes the same change (on a \nhunk level) to a common ancestor. It'll identify this as \"the branches \nagree on a change\" rather than \"the branches conflict\". Also, \"rebase\" \nwill try the 3-way merge mechanism, so it will be able to sort this out.\n\nThe interesting case is when both branches have the same logical change, \nbut one of them is done better than the other. When you merge these, \nyou'll have to select the better one by hand in a conflict resolution.\n\n> > Sometimes, clean up bits that aren't ideal\n> > $ git add -i\n> > Add the good parts\n> > $ git checkout . (revert the working tree to the index)\n> > $ make test (did I extract the change correctly?)\n> > $ git commit\n> > Write a good message, sign off, etc\n> > $ git checkout mixed-work\n> > $ git rebase -i submit\n> \n> ... Ah I see, we throw away old commits anyway with rebasing.\n\nYup. The old commits are there to save us when we make good changes and \nundo them before getting to a finished state. Once we reach a finished \nstate, we intend to throw them away.\n\n> > Often, resolve easy conflicts where my mixed-work branch introduced bugs\n> > that I fixed later and have now adopted the fixed code\n> >\n> > Then I repeat until I don't have any more good changes in mixed-work\n> > (either I have nothing, only debugging cruft, or only stuff I haven't\n> > gotten to work yet). If there's nothing but cruft, I've fully merged the\n> > topic, and I delete the branch.\n> >\n> > Eventually, I'm satisfied with what I've cleaned up, and I do:\n> > $ git push origin submit:master\n> >\n> > Also, I generally have a bunch of \"mixed-work\" branches, each containing\n> > different stuff that isn't ready. I'll periodicly go through all of them\n> > and rebase onto \"submit\" or \"origin/master\" (or, sometimes, give up on\n> > them and delete them).\n> >\n> > (One thing that would be nice to have is a \"git apply --interactive\" which\n> > applies the user's choice of hunks, like \"git add -i\" adds them)\n> \n> I totally agree.\n> \n> I would appriciate rebase --copy option, which doesn't move, but copy\n> the changelists like cherry-pick.\n\nThere's work in progress on a generalization of \"rebase -i\" that could be \nseeded with the \"cherry-pick\" operations instead of the \"rebase\" \noperations. I think that's what you'd like. On the other hand, remember \nthat you can just make a new branch based on your endpoint and rebase it \non your upstream; there's no reason that you can't \"unzip\" the history \npast the point where the branch you're modifying was created.\n\n> Then we could use rebase -i (with edit) instead of apply.\n> \n> PS\n> Why after edit in rebase -i the change is already commited? I always\n> have to reset;add -i\n\nThere's (currently) no equivalent of the index (storing the contents of \nthe commit in progress) for the message (and author info, etc). On the \nother hand, you can use \"git commit --amend\" to alter the commit on top \n(including the files), and you can do \"git diff HEAD HEAD^ | git apply\" to \nget reverts into your worktree that you can add (or not add).\n\nThe common case for edit, I think, is that things are mostly correct, but \nthere's a wrong change; with the change already committed, it's easy to \nchange it to what it should be and \"git commit -a --amend\".\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"98195","messageId":"c55009e70812171431l7eab33b2x28c5b4360118880b@mail.gmail.com","threadId":"16726","inReplyTo":"alpine.LNX.1.00.0812171500070.19665@iabervon.org","subject":"Re: How to maintain private/secret/confidential branch.","fromName":"Łukasz Lew","fromEmail":"lukasz.lew@gmail.com","sentAt":"2008-12-17T22:31:58Z","receivedAt":"2008-12-17T22:31:58Z","isPatch":false,"sender":{"key":"lukasz.lew@gmail.com","avatar":"https://gravatar.com/avatar/824c7ecf4e2ee1e37a2e3b7dd58d4a745cb68855f58d06a5cb861b0b42531dea?d=mp&s=160"},"body":"2008/12/17 Daniel Barkalow <barkalow@iabervon.org>:\n> On Wed, 17 Dec 2008, Łukasz Lew wrote:\n>\n>> Well, I am still a beginner in git. I just switched from mercurial.\n>> Some inline follows:\n>>\n>> 2008/12/15 Daniel Barkalow <barkalow@iabervon.org>:\n>> > On Sun, 14 Dec 2008, Łukasz Lew wrote:\n>> >\n>> >> Hi Alexander,\n>> >>\n>> >> On Sun, Dec 14, 2008 at 17:06, Alexander Potashev <aspotashev@gmail.com> wrote:\n>> >> > Hello, Łukasz!\n>> >> >\n>> >> > On 16:38 Sun 14 Dec     , Łukasz Lew wrote:\n>> >> >> Thanks Nick, thats really helpful (and surprisingly simple).\n>> >> >> I have a couple more questions:\n>> >> >>\n>> >> >> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:\n>> >> >> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:\n>> >> >> >> I don't know how to make such a scenario work:\n>> >> >> >> - two repositories: pub, priv\n>> >> >> >> - priv is clone/branch of pub\n>> >> >> >> - there is some constant developement both in pub and priv\n>> >> >> >> - there are regular syncs with pub in priv\n>> >> >> >>\n>> >> >> >> Problem:\n>> >> >> >> Occasionally I want to push some changes from priv to pub.\n>> >> >> >> Then after syncing with pub I want to get as few conflicts as possible.\n>> >> >> >>\n>> >> >> >> Is it possible to do with git?\n>> >> >> >\n>> >> >> > Git can do almost anything. One should instead ask \"How to do this\n>> >> >> > with git?\" :-)\n>> >> >>\n>> >> >> So I've heard, but not yet experienced it myself. I'm thrilled to try.\n>> >> >>\n>> >> >> >\n>> >> >> > If I understand your problem, you could solve it with git cherry-pick\n>> >> >> > and rebase. On priv, make a for-public branch from a pub branch. Then\n>> >> >> > cherry-pick the commits you want from your private branch into the\n>> >> >> > for-public branch.\n>> >> >>\n>> >> >> That almost works. Can I somehow split existing commits just like in git-add -p?\n>> >> > It's, however, better to make more commits to not experience the need of\n>> >> > commit splitting.\n>> >>\n>> >> Indeed good advice and best practice, but another best practice is to\n>> >> not commit not compiling state.\n>> >\n>> > In your private branches, it's actually good practice to commit all sorts\n>> > of junk. That way, when you mess up badly while trying to get it to\n>> > compile, you won't have lost your work. Of course, that means your commits\n>> > are going to need more cleanup before going public.\n>>\n>> I started to follow your advise.\n>> Then I rebase -i.\n>> I found out I need more precise commit messages. :)\n>\n> One useful strategy is to have a second shell and do \"git show <hash>\" to\n> figure out what you did in that misc commit.\n\nIndeed!\n\n>\n>> >> My common scenario is that I code a big change in priv repository, and\n>> >> after that I find that some of its parts can and should be moved to\n>> >> pub.\n>> >\n>> > I usually end up with my private branch containing the public branch, plus\n>> > a bunch of commits that introduce: bugs, later fixed; mixed improvements;\n>> > and debugging cruft. I want to generate nice commits that are individual\n>> > improvements. I generally do:\n>> > $ git checkout -b submit origin/master (the first time, to set it up)\n>> >\n>> > $ git checkout submit\n>> > $ git diff submit mixed-work\n>> > look at it for good changes, find some in file1 and file2\n>> > $ git diff submit mixed-work -- file1 file2 | git apply\n>>\n>> But with this command we do not preserve objects identity.\n>> I.e: when you merge with mixed-work you have duplicate changes.\n>> Is it ok?\n>\n> Git is very good about recognizing duplicate changes in 3-way situations.\n> That is, merging two branches, each of which makes the same change (on a\n> hunk level) to a common ancestor. It'll identify this as \"the branches\n> agree on a change\" rather than \"the branches conflict\". Also, \"rebase\"\n> will try the 3-way merge mechanism, so it will be able to sort this out.\n\nI found that already. And I have to say that I am delighted.\nThis is absolutely splendid.\n\n>\n> The interesting case is when both branches have the same logical change,\n> but one of them is done better than the other. When you merge these,\n> you'll have to select the better one by hand in a conflict resolution.\n>\n>> > Sometimes, clean up bits that aren't ideal\n>> > $ git add -i\n>> > Add the good parts\n>> > $ git checkout . (revert the working tree to the index)\n>> > $ make test (did I extract the change correctly?)\n>> > $ git commit\n>> > Write a good message, sign off, etc\n>> > $ git checkout mixed-work\n>> > $ git rebase -i submit\n>>\n>> ... Ah I see, we throw away old commits anyway with rebasing.\n>\n> Yup. The old commits are there to save us when we make good changes and\n> undo them before getting to a finished state. Once we reach a finished\n> state, we intend to throw them away.\n>\n>> > Often, resolve easy conflicts where my mixed-work branch introduced bugs\n>> > that I fixed later and have now adopted the fixed code\n>> >\n>> > Then I repeat until I don't have any more good changes in mixed-work\n>> > (either I have nothing, only debugging cruft, or only stuff I haven't\n>> > gotten to work yet). If there's nothing but cruft, I've fully merged the\n>> > topic, and I delete the branch.\n>> >\n>> > Eventually, I'm satisfied with what I've cleaned up, and I do:\n>> > $ git push origin submit:master\n>> >\n>> > Also, I generally have a bunch of \"mixed-work\" branches, each containing\n>> > different stuff that isn't ready. I'll periodicly go through all of them\n>> > and rebase onto \"submit\" or \"origin/master\" (or, sometimes, give up on\n>> > them and delete them).\n>> >\n>> > (One thing that would be nice to have is a \"git apply --interactive\" which\n>> > applies the user's choice of hunks, like \"git add -i\" adds them)\n>>\n>> I totally agree.\n>>\n>> I would appriciate rebase --copy option, which doesn't move, but copy\n>> the changelists like cherry-pick.\n>\n> There's work in progress on a generalization of \"rebase -i\" that could be\n> seeded with the \"cherry-pick\" operations instead of the \"rebase\"\n> operations. I think that's what you'd like.\n\nI always wanted to have system that would allow me manipulation of\npatches as features.\nI.e: I have one patch for feature X, one for Y, one for debugging X,\none for debugging Y, etc.\nThen I would just pick some of them, work with them to create new ones.\n\nThe basic operations would be use/unuse patch, combine sequence of\npatches into one (with commit messages of subpatches saved somewhere),\nuncombine patch into sequence of patches.\nEasy way of spliting atomic patch (diff) into several more so I can\nadd more commit messages.\n\nNow this would resemble directory structure, I could copy/move/remove\npatches from/to various bigger packs of patches. Merging would detect\nduplicates of course.\n\nGit took me for the first time close to this ideal.\n\n> On the other hand, remember\n> that you can just make a new branch based on your endpoint and rebase it\n> on your upstream; there's no reason that you can't \"unzip\" the history\n> past the point where the branch you're modifying was created.\n\nI never thought about that. It works indeed.\n\n>\n>> Then we could use rebase -i (with edit) instead of apply.\n>>\n>> PS\n>> Why after edit in rebase -i the change is already commited? I always\n>> have to reset;add -i\n>\n> There's (currently) no equivalent of the index (storing the contents of\n> the commit in progress) for the message (and author info, etc). On the\n> other hand, you can use \"git commit --amend\" to alter the commit on top\n> (including the files), and you can do \"git diff HEAD HEAD^ | git apply\" to\n> get reverts into your worktree that you can add (or not add).\n\nGood idea, thanks.\nBTW is it diff | apply the same as revert --no-commit?\n\n>\n> The common case for edit, I think, is that things are mostly correct, but\n> there's a wrong change; with the change already committed, it's easy to\n> change it to what it should be and \"git commit -a --amend\".\n>\n>        -Daniel\n> *This .sig left intentionally blank*\n"},{"id":"98235","messageId":"alpine.LNX.1.00.0812180236190.19665@iabervon.org","threadId":"16726","inReplyTo":"c55009e70812171431l7eab33b2x28c5b4360118880b@mail.gmail.com","subject":"Re: How to maintain private/secret/confidential branch.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-12-18T08:03:48Z","receivedAt":"2008-12-18T08:03:48Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 17 Dec 2008, Łukasz Lew wrote:\n\n> >> > Often, resolve easy conflicts where my mixed-work branch introduced bugs\n> >> > that I fixed later and have now adopted the fixed code\n> >> >\n> >> > Then I repeat until I don't have any more good changes in mixed-work\n> >> > (either I have nothing, only debugging cruft, or only stuff I haven't\n> >> > gotten to work yet). If there's nothing but cruft, I've fully merged the\n> >> > topic, and I delete the branch.\n> >> >\n> >> > Eventually, I'm satisfied with what I've cleaned up, and I do:\n> >> > $ git push origin submit:master\n> >> >\n> >> > Also, I generally have a bunch of \"mixed-work\" branches, each containing\n> >> > different stuff that isn't ready. I'll periodicly go through all of them\n> >> > and rebase onto \"submit\" or \"origin/master\" (or, sometimes, give up on\n> >> > them and delete them).\n> >> >\n> >> > (One thing that would be nice to have is a \"git apply --interactive\" which\n> >> > applies the user's choice of hunks, like \"git add -i\" adds them)\n> >>\n> >> I totally agree.\n> >>\n> >> I would appriciate rebase --copy option, which doesn't move, but copy\n> >> the changelists like cherry-pick.\n> >\n> > There's work in progress on a generalization of \"rebase -i\" that could be\n> > seeded with the \"cherry-pick\" operations instead of the \"rebase\"\n> > operations. I think that's what you'd like.\n> \n> I always wanted to have system that would allow me manipulation of\n> patches as features.\n> I.e: I have one patch for feature X, one for Y, one for debugging X,\n> one for debugging Y, etc.\n> Then I would just pick some of them, work with them to create new ones.\n> \n> The basic operations would be use/unuse patch, combine sequence of\n> patches into one (with commit messages of subpatches saved somewhere),\n> uncombine patch into sequence of patches.\n> Easy way of spliting atomic patch (diff) into several more so I can\n> add more commit messages.\n> \n> Now this would resemble directory structure, I could copy/move/remove\n> patches from/to various bigger packs of patches. Merging would detect\n> duplicates of course.\n> \n> Git took me for the first time close to this ideal.\n\nGit works from the point of view of a developer producing the ideal \ndevelopment history that doesn;t (necessarily) include false starts, bugs \nfixed in private, and changes mixed together. Or rather, git allows a \ndeveloper to make commits again knowing the full outcome of the series.\n\nIt also works from the point of view of a maintainer who merges or does \nnot merge the output of developers working in this mode.\n\nIt doesn't really quite handle the work of an integrator whose work is to \nmanage a patch queue. I think it needs some additional tools which allow \nthe user do work which consists of operations like \"replace this \npatch/branch with a new version\", \"suppress this patch/branch\", \"reorder \nthese patches/branches\", and the main thing: \"produce a version of my \ncurrent series with conflict resolutions\"\n\nThis would actually be really helpful to have explicitly represented, so \nthat people could actually bisect the -mm series to find the operation \nthat Andrew did that caused a problem to enter the series, which would be \nsomething like adding a patch that doesn't work with other patches in the \nseries. Note that this is different from bisecting within the failing \nstate of the -mm tree, which finds where the series seen as a difference \nfrom mainline, fails; if you know that -mm yesterday works and -mm today \nfails, the difference might be that a branch merged early in the series \nwas updated to a version incompatible with a branch later in the series \nthat hasn't changed, and you'd want to finger the update rather than the \npoint in the series where kernels start failing.\n\n> > On the other hand, remember\n> > that you can just make a new branch based on your endpoint and rebase it\n> > on your upstream; there's no reason that you can't \"unzip\" the history\n> > past the point where the branch you're modifying was created.\n> \n> I never thought about that. It works indeed.\n\nThere's a lot you can do when branches are as cheap and flexible as git's \nbranches are.\n\n> >> Then we could use rebase -i (with edit) instead of apply.\n> >>\n> >> PS\n> >> Why after edit in rebase -i the change is already commited? I always\n> >> have to reset;add -i\n> >\n> > There's (currently) no equivalent of the index (storing the contents of\n> > the commit in progress) for the message (and author info, etc). On the\n> > other hand, you can use \"git commit --amend\" to alter the commit on top\n> > (including the files), and you can do \"git diff HEAD HEAD^ | git apply\" to\n> > get reverts into your worktree that you can add (or not add).\n> \n> Good idea, thanks.\n> BTW is it diff | apply the same as revert --no-commit?\n\nLargely, although you can give the diff/apply pair paths you want to \nrevert, and not revert the whole thing. And the second commit can be \nanything with the diff/apply pair, not just HEAD^, which is what revert \ndoes, so it's a worthwhile generalization to understand.\n\n\t-Daniel\n*This .sig left intentionally blank*"}]}