{"thread":{"id":"14372","subject":"Idea: \"live branches\"?","startedAt":"2008-07-09T09:56:36Z","lastAt":"2008-07-09T17:00:46Z","messageCount":3,"participants":["Jan Rychter","Avery Pennarun","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"82729","messageId":"m28wwbz8h7.fsf@tnuctip.rychter.com","threadId":"14372","inReplyTo":null,"subject":"Idea: \"live branches\"?","fromName":"Jan Rychter","fromEmail":"jan@rychter.com","sentAt":"2008-07-09T09:56:36Z","receivedAt":"2008-07-09T09:56:36Z","isPatch":false,"sender":{"key":"jan@rychter.com","avatar":null},"body":"I've been trying out a number of DVCS tools recently and finally found\nthat git is the best fit for me. There is one thing I found missing,\nthough.\n\nThe problem is that there are usually two distinct concepts:\n\n-- topic branches, representing longer-term ongoing development in a\n certain direction, large-scale features, etc,\n-- patches that represent complete functionality, to be committed\n upstream, but continuously improved.\n\nMy local repositories are usually a combination of both. I will often\nhave a number of feature patches that I don't want to push upstream just\nyet. These patches change often. My topic branches will all want to use\nthem, in their latest form/revision. This is not a workflow that you can\neasily represent with any of today's DVCS tools. One can do this with\ncareful cherry-picking and merging, but it is a lot of manual work and\nclutters up history with lots of merge commits.\n\nStGIT is *almost* there. It lets you manage a pile of patches, modify\nthem, apply them selectively, as well as update the mainstream\nrepository and reapply local patches. It fails in two ways: 1) when you\nwant to reuse the same patches on multiple branches. One-way migration\nis doable (not pleasant, but doable), but if you modify a patch in one\nof your branches, your other branches which use the same patch will not\nsee the change. And 2) StGIT patches are simple by design, and you can't\nhave internal commit history within a patch, which is a problem for\nlarger features.\n\nWhich brings me to my point. I think we need a system that can maintain\n\"live branches\". We already have impressive systems for dealing with\npatches and we have made the patch into a first-class citizen of our\nsoftware development world. Now, instead of statically tracking commits\nand following a one-way development history, let's have live branches --\nbranches that can change, causing code that depends on them to change.\n\nThe way this would work is I would have one or two long-term development\nbranches, and each of those would depend on a list of \"live branches\",\nmanaged by a tool similar to StGIT. I should be able to commit to either\nthe main development branch, or to one of the \"live branches\", in which\ncase I should be able to easily \"resync\" the main development branch (do\na merge or a rebase, but I would prefer the tool to first remove old\nmerge commits, so as not to clutter history). \n\nThe tool should also let me pick a commit I've made and move it to one\nof the live branches easily (similar to stgit).\n\nDoes this make sense, or am I missing something very obvious?\n\n--J.\n\nPS: I am obviously aware that this is something which is suitable for\nlocal development work only.\n"},{"id":"82731","messageId":"32541b130807090948q65d64ea9s7a3c0639c2f2daa2@mail.gmail.com","threadId":"14372","inReplyTo":"m28wwbz8h7.fsf@tnuctip.rychter.com","subject":"Re: Idea: \"live branches\"?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-09T16:48:25Z","receivedAt":"2008-07-09T16:48:25Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/9/08, Jan Rychter wrote:\n> The way this would work is I would have one or two long-term development\n> branches, and each of those would depend on a list of \"live branches\",\n> managed by a tool similar to StGIT. I should be able to commit to either\n> the main development branch, or to one of the \"live branches\", in which\n> case I should be able to easily \"resync\" the main development branch (do\n> a merge or a rebase, but I would prefer the tool to first remove old\n> merge commits, so as not to clutter history).\n\nHmm, git rebase already removes old merge commits. In my own\nworkflow, I tend to do repeated merges of the \"live branch\" into my\nfeature branches during development, then do a rebase occasionally to\nclean up the patch set, especially right before merging it into\nmaster. This seems pretty painless to me. What specific problem are\nyou having that prevents this from working?\n\nHave fun,\n\nAvery\n"},{"id":"82732","messageId":"alpine.DEB.1.00.0807091750350.18205@racer","threadId":"14372","inReplyTo":"m28wwbz8h7.fsf@tnuctip.rychter.com","subject":"Re: Idea: \"live branches\"?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-09T17:00:46Z","receivedAt":"2008-07-09T17:00:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 9 Jul 2008, Jan Rychter wrote:\n\n> Which brings me to my point. I think we need a system that can maintain \n> \"live branches\". We already have impressive systems for dealing with \n> patches and we have made the patch into a first-class citizen of our \n> software development world. Now, instead of statically tracking commits \n> and following a one-way development history, let's have live branches -- \n> branches that can change, causing code that depends on them to change.\n> \n> The way this would work is I would have one or two long-term development \n> branches, and each of those would depend on a list of \"live branches\", \n> managed by a tool similar to StGIT. I should be able to commit to either \n> the main development branch, or to one of the \"live branches\", in which \n> case I should be able to easily \"resync\" the main development branch (do \n> a merge or a rebase, but I would prefer the tool to first remove old \n> merge commits, so as not to clutter history).\n\nIt should be very easy to write a small shell script which expects some \nconfig variable\n\n\tbranch..liveBranches\n\nwhich contains a list of (local) branches. It would then just look which \nof those branches contains newer commits, finds the merges that pulled \nthose branches in, and redoes those merges (and the commits). It would \nrely heavily on \"git reset\" and on an untampered-with merge message.\n\nThe main loop would look a little bit like this:\n\n\tgit rev-list --parents ^ |\n\twhile read commit parent otherparents\n\tdo\n\t\tcase \"$otherparents\" in\n\t\t'')\n\t\t\tgit cherry-pick $commit\n\t\t;;\n\t\t*)\n\t\t\tcase \" $commit \" in\n\t\t\t\" $mergestoberedone \")\n\t\t\t;;\n\t\t\t*)\n\t\t\t\tmessage=\"$(git cat-file commit $commit |\n\t\t\t\t\tsed '/^$/q')\"\n\t\t\t\tgit merge -m \"$message\" $otherparents\n\t\t\t;;\n\t\tesac\n\tdone\n\t# merge changes branches\n\nNo wizardry required.\n\n> The tool should also let me pick a commit I've made and move it to one \n> of the live branches easily (similar to stgit).\n\nThat is relatively simple, using \"git checkout && git cherry-pick \n && git checkout && git resync-live-branches\".\n\nI strongly suggest writing that script, and seeing if it is useful for \nyou. If it is, just submit it and earn all the glory.\n\nHth,\nDscho\n"}]}