{"thread":{"id":"36692","subject":"[ANNOUNCE] git reintegrate v0.3; manager of integration branches","startedAt":"2014-05-19T00:33:57Z","lastAt":"2014-05-24T04:24:17Z","messageCount":9,"participants":["Felipe Contreras","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"242135","messageId":"53795175664d5_10da88d308ce@nysa.notmuch","threadId":"36692","inReplyTo":null,"subject":"[ANNOUNCE] git reintegrate v0.3; manager of integration branches","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-19T00:33:57Z","receivedAt":"2014-05-19T00:33:57Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\ngit reintegrate is a helper tool to manage integration branches, it\nhas all the options of other known tools.\n\nThis is a rewrite of John Keeping's git-integration in Ruby, it has\nessentially the same features and passes all the git-integration\ntests, but it has more features.\n\nOne feature that is missing from git-integration is the ability to\nparse existing integration branches.\n\nTo give a try you can do:\n\n git clone https://github.com/gitster/git/\n cd git\n git fetch -u origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'\n git checkout pu\n git reintegrate --generate pu master\n\nWhich will generate the integration instructions for you:\n\n % git reintegrate --cat\n base master\n merge jl/submodule-mv\n\n Moving a regular file in a repository with a .gitmodules file was\n producing a warning 'Could not find section in .gitmodules where\n path='.\n\n merge ap/remote-hg-unquote-cquote\n\n A fast-import stream expresses a pathname with funny characters by\n quoting them in C style; remote-hg remote helper forgot to unquote\n such a path.\n\n merge jk/for-each-ref-skip-parsing\n merge jk/pack-corruption-post-mortem\n merge jk/reset-p-current-head-fix\n\n \"git reset -p HEAD\" has codepath to special case it from resetting\n to contents of other commits, but recent change broke it.\n\n ...\n\nIt also has support for \"evil merges\", so it should be perfectly\nusable for git.git maintenance.\n\nYou can edit the instructions with `git reintegrate --edit`.\n\nThe simplest way to begin an integration branch is with:\n\n git reintegrate --create pu master\n git reintegrate --add=branch1 --add=branch2 --add=branch3\n\nTo generate the integration branch run `git reintegrate --rebuild`, if\nthere are merge conflicts, solve them and continue with `git\nreintegrate --continue`.\n\nDespite having more features, the code is actually smaller thanks to\nRuby awesomeness.\n\nEnjoy.\n\nhttps://github.com/felipec/git-reintegrate\n\nChanges since v0.1:\n\n * Add support for empty commits\n * Add support for pause command\n * Update manpage\n * Add bash completion\n\nFelipe Contreras (26):\n Add copyright and license notices\n Fix EDITOR support with arguments\n Trivial style cleanup\n Improve command regex\n Add support for empty commits\n test: improve check_int()\n Add support for 'pause' command\n doc: rename manpage file\n doc: update options\n doc: add description\n doc: add missing instruction commands\n doc: cleanup . command\n Verify branches after parsing\n test: fix test names\n Remove unused statements\n Update README\n test: cleanup instruction sheets\n Update copyright notices\n Add bash completion\n build: add installation stuff\n readme: add installation instructions\n Add gitignore for documentation\n trvis: initial configuration\n travis: add verbosity\n test: add test-lib helper\n travis: remove Ruby 1.8\n\n-- \nFelipe Contreras\n"},{"id":"242202","messageId":"xmqqha4lxyqt.fsf@gitster.dls.corp.google.com","threadId":"36692","inReplyTo":"53795175664d5_10da88d308ce@nysa.notmuch","subject":"Re: [ANNOUNCE] git reintegrate v0.3; manager of integration branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-19T21:08:42Z","receivedAt":"2014-05-19T21:08:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> ...\n> Which will generate the integration instructions for you:\n>\n> % git reintegrate --cat\n> base master\n> merge jl/submodule-mv\n>\n> Moving a regular file in a repository with a .gitmodules file was\n> producing a warning 'Could not find section in .gitmodules where\n> path='.\n>\n> merge ap/remote-hg-unquote-cquote\n>\n> It also has support for \"evil merges\", so it should be perfectly\n> usable for git.git maintenance.\n\nYeah, it sounds like it is almost there.\n\nI think the infrastructure to maintain \"What's cooking\" could be\nupdated to use these comments after \"merge\" instructions if I wanted\nto.\n\nI build two branches on top of 'master', one is called 'jch' and has\na marker line somewhere that says '### match next' that is turned\ninto an empty commit, and 'pu' that is built on top of the tip of\n'jch'. The marker line is used to apply only an earlier part of the\ninstruction stream to build 'jch' on top of 'master' on top of\n'next' (i.e. \"base master\" in the above example will not be applied\nto hard-reset 'next' to match master) and stop there, and is meant\nto be a way to sanity check 'next' (which is made by repeated\nincremental merges on top of 'master' without rewinding) by\ncomparing the \"### match next\" commit between 'master' and 'jch'\n(which is made afresh from 'master' by taking only the necessary\ntopics). They must match or I caught a possible mismerge on 'next'.\n\nI presume that the workflow can be mimicked by having another branch\n'match-next' and building it on top of 'master', and then building\n'jch' on top of it, and then building 'pu' on top of it. Then you\nshould be able to play 'match-next' instruction on top of 'next'\n(provided that there is a way to tell it to replay on HEAD and\nignore \"base\" and have \"merge\" instruction become a no-op when the\nbranch has already been merged).\n\nFun.\n"},{"id":"242326","messageId":"537bc3e1c605c_a6f166b3088f@nysa.notmuch","threadId":"36692","inReplyTo":"xmqqha4lxyqt.fsf@gitster.dls.corp.google.com","subject":"Re: [ANNOUNCE] git reintegrate v0.3; manager of integration branches","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-20T21:06:41Z","receivedAt":"2014-05-20T21:06:41Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > ...\n> > Which will generate the integration instructions for you:\n> >\n> > % git reintegrate --cat\n> > base master\n> > merge jl/submodule-mv\n> >\n> > Moving a regular file in a repository with a .gitmodules file was\n> > producing a warning 'Could not find section in .gitmodules where\n> > path='.\n> >\n> > merge ap/remote-hg-unquote-cquote\n> >\n> > It also has support for \"evil merges\", so it should be perfectly\n> > usable for git.git maintenance.\n> \n> Yeah, it sounds like it is almost there.\n> \n> I think the infrastructure to maintain \"What's cooking\" could be\n> updated to use these comments after \"merge\" instructions if I wanted\n> to.\n> \n> I build two branches on top of 'master', one is called 'jch' and has\n> a marker line somewhere that says '### match next' that is turned\n> into an empty commit, and 'pu' that is built on top of the tip of\n> 'jch'. The marker line is used to apply only an earlier part of the\n> instruction stream to build 'jch' on top of 'master' on top of\n> 'next' (i.e. \"base master\" in the above example will not be applied\n> to hard-reset 'next' to match master) and stop there, and is meant\n> to be a way to sanity check 'next' (which is made by repeated\n> incremental merges on top of 'master' without rewinding) by\n> comparing the \"### match next\" commit between 'master' and 'jch'\n> (which is made afresh from 'master' by taking only the necessary\n> topics). They must match or I caught a possible mismerge on 'next'.\n> \n> I presume that the workflow can be mimicked by having another branch\n> 'match-next' and building it on top of 'master', and then building\n> 'jch' on top of it, and then building 'pu' on top of it. Then you\n> should be able to play 'match-next' instruction on top of 'next'\n> (provided that there is a way to tell it to replay on HEAD and\n> ignore \"base\" and have \"merge\" instruction become a no-op when the\n> branch has already been merged)\n\nOr have an option to specify a dynamic instruction sheet, so you can cat\nthe instructions of 'match-next' and replace the base. However, I don't\nsee the point of re-applying the branches for 'next' if you already know\nthat 'next' and 'match-next' are the same.\n\nI would have two branches: 1) 'match-next' (or 'integration-next') that\nhas the instructions to build 'next' on top of 'master', and 2) 'pu',\nwhich has the instructions to build 'pu' on top of 'next'.\n\n-- \nFelipe Contreras\n"},{"id":"242328","messageId":"xmqqtx8krvem.fsf@gitster.dls.corp.google.com","threadId":"36692","inReplyTo":"537bc3e1c605c_a6f166b3088f@nysa.notmuch","subject":"Re: [ANNOUNCE] git reintegrate v0.3; manager of integration branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-20T21:29:37Z","receivedAt":"2014-05-20T21:29:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Or have an option to specify a dynamic instruction sheet, so you can cat\n> the instructions of 'match-next' and replace the base. However, I don't\n> see the point of re-applying the branches for 'next' if you already know\n> that 'next' and 'match-next' are the same.\n\nThe output from Reintegrate script (in 'todo') only lists the names\nof topic branches (or something like \"xx/topic~4\" when the topic is\nnot fully merged yet), and a topic branch may acquire a follow-up\nchange (or two) on top (there is a machinery to see if xx/topic~4\nis still valid in such a case and update the offset as needed).\n\nRebuilding 'jch' on top of 'master' with the same insn sheet will\nthen merge the updated topic branch in its entirety, and the new\ncommits on the topic branch somehow needs to go to 'next' for the\n\"match next\" on 'jch' and 'next' to be in sync (in addition, updated\n'master' must be merged to 'next', but that goes without saying).\n\nIn other words, I already know that 'next' and \"match next\" are not\nthe same, that they must become the same, and there needs a way to\nmake them so.\n\nAnd that is done by re-running the insn sheet for 'jch' up to the\n\"match next\" mark, merging the topic that are not fully merged to\n'next' while ignoring the ones that already are fully in 'next'.\n"},{"id":"242334","messageId":"537bcbf7efd4_1d08f2d2f8a7@nysa.notmuch","threadId":"36692","inReplyTo":"xmqqtx8krvem.fsf@gitster.dls.corp.google.com","subject":"Re: [ANNOUNCE] git reintegrate v0.3; manager of integration branches","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-20T21:41:11Z","receivedAt":"2014-05-20T21:41:11Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Or have an option to specify a dynamic instruction sheet, so you can cat\n> > the instructions of 'match-next' and replace the base. However, I don't\n> > see the point of re-applying the branches for 'next' if you already know\n> > that 'next' and 'match-next' are the same.\n> \n> The output from Reintegrate script (in 'todo') only lists the names\n> of topic branches (or something like \"xx/topic~4\" when the topic is\n> not fully merged yet), and a topic branch may acquire a follow-up\n> change (or two) on top (there is a machinery to see if xx/topic~4\n> is still valid in such a case and update the offset as needed).\n> \n> Rebuilding 'jch' on top of 'master' with the same insn sheet will\n> then merge the updated topic branch in its entirety, and the new\n> commits on the topic branch somehow needs to go to 'next' for the\n> \"match next\" on 'jch' and 'next' to be in sync (in addition, updated\n> 'master' must be merged to 'next', but that goes without saying).\n> \n> In other words, I already know that 'next' and \"match next\" are not\n> the same, that they must become the same, and there needs a way to\n> make them so.\n> \n> And that is done by re-running the insn sheet for 'jch' up to the\n> \"match next\" mark, merging the topic that are not fully merged to\n> 'next' while ignoring the ones that already are fully in 'next'.\n\nThere could be a new --merge-missing option that takes the instruction\nsheet of an integration branch (e.g. 'match-next'), ignores the 'base'\napplies them in 'HEAD' but only when the topic branch isn't already in\n'HEAD'.\n\nI'm not sure what would be the usefulness of using things like\n'xx/topic~4'.\n\n-- \nFelipe Contreras\n"},{"id":"242338","messageId":"xmqqa9acrrsv.fsf@gitster.dls.corp.google.com","threadId":"36692","inReplyTo":"537bcbf7efd4_1d08f2d2f8a7@nysa.notmuch","subject":"Re: [ANNOUNCE] git reintegrate v0.3; manager of integration branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-20T22:47:28Z","receivedAt":"2014-05-20T22:47:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> I'm not sure what would be the usefulness of using things like\n> 'xx/topic~4'.\n\nAs a notation it is not very pretty ;-).\n\nImagine that xx/topic is about a multistep introduction of a\nbackward incompatible feature. The beginning part of the series up\nto xx/topic~4 are the step to start warning (i.e. \"will change---do\nthis to keep the old one or do that to live in the future\"),\nxx/topic~3..xx/topic~1 are the next step to flip the default and\nstill keep warning (i.e. \"have changed---do this to keep the old one\nor do that to live in the present\"), and the final xx/topic is the\nendgame where everybody lives with the new default with no warning,\nwithout having to know what the old default was.\n\nWhile the topic is being prepared for the next release, the insn\nsheet for 'jch' would have xx/topic~4 before \"match next\" marker,\nand then an entry for xx/topic~1 somewhere after it, and finally an\nentry for xx/topic (i.e. the tip, final commit). When the first\nstep cooked well enough in 'next', selected entries of 'jch' insn\nsheet before \"match next\" ones are used to merge them to 'master'\nand the part up to xx/topic~4 (but not later patches on the topic\nbranch) will be part of the upcoming release.\n\nYou could simulate that with multiple branches stacked on top of\neach other, but there are times when keeping things together in a\nsingle branch is more handy.\n\nIn restrospect, if I found xx/topic~4 too ugly, I might have instead\nmade \"branches stacked on top of each other\" easier to manage, but\nhaving Reintegrate support \"in the middle of a branch\" was simpler.\nThey are both OK solutions to the same problem, and I didn't have to\nsolve it both ways ;-)\n"},{"id":"242340","messageId":"CAMP44s03--Y8FJigWFw3kniULmUGNA7+8U=fvHn0QoC2K_eO1A@mail.gmail.com","threadId":"36692","inReplyTo":"xmqqa9acrrsv.fsf@gitster.dls.corp.google.com","subject":"Re: [ANNOUNCE] git reintegrate v0.3; manager of integration branches","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-20T22:54:23Z","receivedAt":"2014-05-20T22:54:23Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, May 20, 2014 at 5:47 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> I'm not sure what would be the usefulness of using things like\n>> 'xx/topic~4'.\n>\n> As a notation it is not very pretty ;-).\n>\n> Imagine that xx/topic is about a multistep introduction of a\n> backward incompatible feature. The beginning part of the series up\n> to xx/topic~4 are the step to start warning (i.e. \"will change---do\n> this to keep the old one or do that to live in the future\"),\n> xx/topic~3..xx/topic~1 are the next step to flip the default and\n> still keep warning (i.e. \"have changed---do this to keep the old one\n> or do that to live in the present\"), and the final xx/topic is the\n> endgame where everybody lives with the new default with no warning,\n> without having to know what the old default was.\n>\n> While the topic is being prepared for the next release, the insn\n> sheet for 'jch' would have xx/topic~4 before \"match next\" marker,\n> and then an entry for xx/topic~1 somewhere after it, and finally an\n> entry for xx/topic (i.e. the tip, final commit). When the first\n> step cooked well enough in 'next', selected entries of 'jch' insn\n> sheet before \"match next\" ones are used to merge them to 'master'\n> and the part up to xx/topic~4 (but not later patches on the topic\n> branch) will be part of the upcoming release.\n>\n> You could simulate that with multiple branches stacked on top of\n> each other, but there are times when keeping things together in a\n> single branch is more handy.\n>\n> In restrospect, if I found xx/topic~4 too ugly, I might have instead\n> made \"branches stacked on top of each other\" easier to manage, but\n> having Reintegrate support \"in the middle of a branch\" was simpler.\n> They are both OK solutions to the same problem, and I didn't have to\n> solve it both ways ;-)\n\nYes, I see how xx/topic~4 would be useful in the instruction sheet, I\njust didn't see it would be useful to generate that from an existing\nintegration branch. After the explanation above I see how it could be\nuseful to some people (though not all). I'll implement that.\n\n-- \nFelipe Contreras\n"},{"id":"242635","messageId":"53801ea595071_e568c52f816@nysa.notmuch","threadId":"36692","inReplyTo":"xmqqha4lxyqt.fsf@gitster.dls.corp.google.com","subject":"Re: [ANNOUNCE] git reintegrate v0.3; manager of integration branches","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-24T04:23:01Z","receivedAt":"2014-05-24T04:23:01Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> I presume that the workflow can be mimicked by having another branch\n> 'match-next' and building it on top of 'master', and then building\n> 'jch' on top of it, and then building 'pu' on top of it. Then you\n> should be able to play 'match-next' instruction on top of 'next'\n> (provided that there is a way to tell it to replay on HEAD and\n> ignore \"base\" and have \"merge\" instruction become a no-op when the\n> branch has already been merged).\n\nDone.\n\n% git checkout next\n% git reintegrate --apply match-next\n\nhttps://github.com/felipec/git-reintegrate/commit/036395b\n\n-- \nFelipe Contreras\n"},{"id":"242636","messageId":"53801ef17dfb_e568c52f8d4@nysa.notmuch","threadId":"36692","inReplyTo":"CAMP44s03--Y8FJigWFw3kniULmUGNA7+8U=fvHn0QoC2K_eO1A@mail.gmail.com","subject":"Re: [ANNOUNCE] git reintegrate v0.3; manager of integration branches","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-24T04:24:17Z","receivedAt":"2014-05-24T04:24:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Felipe Contreras wrote:\n> Yes, I see how xx/topic~4 would be useful in the instruction sheet, I\n> just didn't see it would be useful to generate that from an existing\n> integration branch. After the explanation above I see how it could be\n> useful to some people (though not all). I'll implement that.\n\nActually it was already supported.\n\nhttps://github.com/felipec/git-reintegrate/commit/f3aa558\n\n-- \nFelipe Contreras\n"}]}