{"thread":{"id":"13765","subject":"Development strategy","startedAt":"2008-06-02T15:51:49Z","lastAt":"2008-06-02T23:35:35Z","messageCount":10,"participants":["Lea Wiemann","Sverre Rabbelier","Jakub Narebski","Johannes Schindelin","Stephan Beyer","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"78377","messageId":"48441715.4010507@gmail.com","threadId":"13765","inReplyTo":null,"subject":"Development strategy","fromName":"Lea Wiemann","fromEmail":"lewiemann@gmail.com","sentAt":"2008-06-02T15:51:49Z","receivedAt":"2008-06-02T15:51:49Z","isPatch":false,"sender":{"key":"lewiemann@gmail.com","avatar":null},"body":"Hi everyone,\n\n[For those uninitiated, this is about my GSoC project about adding \ncaching to Gitweb, on which I am currently working full-time; my branch \nis here: http://repo.or.cz/w/git/gitweb-caching.git]\n\nI'm seeing a process-wise problem arising with my current work on Git.pm \nand Gitweb, in that I'm producing patches at a higher frequency than the \ndeveloper community can handle. Right now, I have a stack of 7 patches \nthat haven't been \"approved\" in any way (i.e. either they are under \ndiscussion or nobody has reviewed them) and that my future work will \ndepend on. Chronologically,\n\n! 2f15087248 perl/Git.pm: add get_hash method\n abd799435c gitweb: use Git.pm, and use its get_hash method\n! 5e53e2e67e t/test-lib.sh: add test_external\n! c5c97f896c Git.pm: fix documentation of hash_object\n! 8db2d73809 test suite for Git.pm\n 261a54ff5b gitweb: removed unused parse_ref method [not posted yet]\n e9166526a3 Git.pm: add get_type method [not posted yet]\n\nThe patches marked \"!\" I cannot change without breaking at least one \nsubsequent patch, so every time I want to make a change to one of those, \nI also need to change at least one subsequent commit, and worse, \nresubmit it to the mailing list. (E.g. the the recent rename from \nparse_rev to get_hash necessitated two extra patches to accommodate the \nchange.)\n\nIf I keep on committing revisions like I'm doing right now, I'll end up \nwith a long queue of interdependent patches of which only the newest few \nare easily changeable. Here are some ideas to prevent this:\n\n1) My current patch frequency is probably too high, in particular if \nminor changes (like method renames or documentation changes) cause \nre-posts of patches. Hence, I suggest that I stay on my branch for now \nand only post patches on which I actually want feedback, without \nreposting corrected versions after getting feedback. That is, no \npatches just for \"please someone approve this\".\n\n2) I should probably also try to squash patches into larger ones. This \nwill make it easier to make changes in older commits, since I don't have \nto edit several commits, and it reduces the probability of merge \nconflicts. I'm not sure how much squashing is appropriate though: For \nexample, would it be okay to squash a fix like \"Git.pm: fix \ndocumentation of hash_object\" into a larger \"Git.pm: add and fix several \nmethods\" commit, where I only mention the documentation-fix in the log \nmessage? It would certainly be helpful in that it reduces the number of \nconflicts, but it will make the logs coarser.\n\n-- Lea\n"},{"id":"78394","messageId":"bd6139dc0806021130p2cc442a3qfe9c00681fdb05e3@mail.gmail.com","threadId":"13765","inReplyTo":"48441715.4010507@gmail.com","subject":"Re: Development strategy","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-06-02T18:30:24Z","receivedAt":"2008-06-02T18:30:24Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, Jun 2, 2008 at 5:51 PM, Lea Wiemann wrote:\n> 2) I should probably also try to squash patches into larger ones. This will\n> make it easier to make changes in older commits, since I don't have to edit\n> several commits, and it reduces the probability of merge conflicts. I'm not\n> sure how much squashing is appropriate though: For example, would it be okay\n> to squash a fix like \"Git.pm: fix documentation of hash_object\" into a\n> larger \"Git.pm: add and fix several methods\" commit, where I only mention\n> the documentation-fix in the log message? It would certainly be helpful in\n> that it reduces the number of conflicts, but it will make the logs coarser.\n\nWhy not go for the win and do both? Keep your commit strategy as is,\nand create a branch whenever you want review, say review-02-06 or such\nand in that branch you squash the commits as appropriate (perhaps\nStGit can help here). These patches are mostly not intended for\ninclusion just yet (but for review only), right? Instead of sending\nall the small commits you send a bigger one, perhaps with a link to\nwhere the branch can be found for easy checkout. You can keep the\nbranch for the a record or delete it after the review and go on with\nthe next branch.\n\nCheers,\n\nSverre, who thinks a few RFC patches are in place soon for git-stats\ntoo and is glad you are doing the fine-tuning wrt patch submission.\n"},{"id":"78395","messageId":"m38wxn1wq8.fsf@localhost.localdomain","threadId":"13765","inReplyTo":"bd6139dc0806021130p2cc442a3qfe9c00681fdb05e3@mail.gmail.com","subject":"Re: Development strategy","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-02T19:09:07Z","receivedAt":"2008-06-02T19:09:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Sverre Rabbelier\" writes:\n\n> Cheers,\n> \n> Sverre, who thinks a few RFC patches are in place soon for git-stats\n> too and is glad you are doing the fine-tuning wrt patch submission.\n\nBy the way, do you have public git repository set up somewhere (for\nexample at repo.or.cz)?\n\nShawn, what is the status of other git GSoC 2008 projects?\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"78397","messageId":"bd6139dc0806021224pf392ec6v291890259d5245f6@mail.gmail.com","threadId":"13765","inReplyTo":"m38wxn1wq8.fsf@localhost.localdomain","subject":"Re: Development strategy","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-06-02T19:24:20Z","receivedAt":"2008-06-02T19:24:20Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, Jun 2, 2008 at 9:09 PM, Jakub Narebski wrote:\n> By the way, do you have public git repository set up somewhere (for\n> example at repo.or.cz)?\n\nYes I do :).\nhttp://repo.or.cz/w/git-stats.git\nI will put up a link at http://alturin.googlepages.com/gsoc2008.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"78398","messageId":"alpine.DEB.1.00.0806022022110.13507@racer.site.net","threadId":"13765","inReplyTo":"m38wxn1wq8.fsf@localhost.localdomain","subject":"Re: Development strategy","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-02T19:24:24Z","receivedAt":"2008-06-02T19:24:24Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 2 Jun 2008, Jakub Narebski wrote:\n\n> \"Sverre Rabbelier\" writes:\n> \n> > Sverre, who thinks a few RFC patches are in place soon for git-stats \n> > too and is glad you are doing the fine-tuning wrt patch submission.\n> \n> By the way, do you have public git repository set up somewhere (for \n> example at repo.or.cz)?\n> \n> Shawn, what is the status of other git GSoC 2008 projects?\n\nLet's not ask Shawn who is overloaded with work already, but the \nmentors/students.\n\nAs for my student, Miklos, who is pretty close to submitting builtin-merge \nrc1 (to be held off until after 1.5.6), he has\n\n\thttp://repo.or.cz/w/git/vmiklos.git\n\nCiao,\nDscho\n"},{"id":"78400","messageId":"20080602193951.GE7648@leksak.fem-net","threadId":"13765","inReplyTo":"m38wxn1wq8.fsf@localhost.localdomain","subject":"Re: Development strategy","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-02T19:39:51Z","receivedAt":"2008-06-02T19:39:51Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"> Shawn, what is the status of other git GSoC 2008 projects?\n\nI don't think he is informed about every project. ;-)\n\nWell, I -- the one who does git-sequencer -- am currently on \nmaking a first prototype (according to a first spec) work/clean ;)\n\nI have a repo at repo.or.cz, but have not yet pushed to it because\nmy compromised Debian SSH key has still access to repo.or.cz and my\nnew one hasn't.\n\nRegards,\n Stephan\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"},{"id":"78403","messageId":"alpine.DEB.1.00.0806022101490.13507@racer.site.net","threadId":"13765","inReplyTo":"20080602193951.GE7648@leksak.fem-net","subject":"Re: Development strategy","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-02T20:02:42Z","receivedAt":"2008-06-02T20:02:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 2 Jun 2008, Stephan Beyer wrote:\n\n> I have a repo at repo.or.cz, but have not yet pushed to it because my \n> compromised Debian SSH key has still access to repo.or.cz and my new one \n> hasn't.\n\nWhy don't you just remove your old account from that repository, add a new \naccount with the new keys, and use that, until Pasky finally integrated \nthe changes to repo.git to change your keys?\n\nCiao,\nDscho\n"},{"id":"78428","messageId":"484475FC.8020804@gmail.com","threadId":"13765","inReplyTo":"bd6139dc0806021130p2cc442a3qfe9c00681fdb05e3@mail.gmail.com","subject":"Re: Development strategy","fromName":"Lea Wiemann","fromEmail":"lewiemann@gmail.com","sentAt":"2008-06-02T22:36:44Z","receivedAt":"2008-06-02T22:36:44Z","isPatch":false,"sender":{"key":"lewiemann@gmail.com","avatar":null},"body":"Sverre Rabbelier wrote:\n> Keep your commit strategy as is [with small commits],\n> and create a branch whenever you want review and in that branch you\n> squash the commits as appropriate\n\nAre you suggesting that the squashed patches get merged, or that the \nsquashed patches get reviewed but the finer-granulated patches get \nmerged? In the former case, I'd probably prefer to work with larger \npatches in the first place (and not just squash them on the review \nbranch), since they are easier to handle -- e.g. I sometimes need to go \nback and change things in earlier commits, and in those cases larger \ncommits are easier.\n\n-- Lea\n"},{"id":"78432","messageId":"bd6139dc0806021604w1a066229idb788a9b918ee24b@mail.gmail.com","threadId":"13765","inReplyTo":"484475FC.8020804@gmail.com","subject":"Re: Development strategy","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-06-02T23:04:01Z","receivedAt":"2008-06-02T23:04:01Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Tue, Jun 3, 2008 at 12:36 AM, Lea Wiemann wrote:\n> Are you suggesting that the squashed patches get merged, or that the\n> squashed patches get reviewed but the finer-granulated patches get merged?\n\nThe latter is what I suggested :). I reckon you'll want ot keep the\nfinger-granulated history for future reference / bisecting, but when\nreviewing that seems overkill.\n\n> In the former case, I'd probably prefer to work with larger patches in the\n> first place (and not just squash them on the review branch), since they are\n> easier to handle -- e.g. I sometimes need to go back and change things in\n> earlier commits, and in those cases larger commits are easier.\n\nIf you don't think you're omitting information you will want later on\n(meaning the more specific commit history), by all means, go with the\nbigger patches. I find it nicer to create small commits, with the plus\nthat it cuts down the size of the commit msg too ;).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"78436","messageId":"7vr6bf5s1k.fsf@gitster.siamese.dyndns.org","threadId":"13765","inReplyTo":"48441715.4010507@gmail.com","subject":"Re: Development strategy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-02T23:35:35Z","receivedAt":"2008-06-02T23:35:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lea Wiemann writes:\n\n> ! 2f15087248 perl/Git.pm: add get_hash method\n> abd799435c gitweb: use Git.pm, and use its get_hash method\n> ! 5e53e2e67e t/test-lib.sh: add test_external\n> ! c5c97f896c Git.pm: fix documentation of hash_object\n> ! 8db2d73809 test suite for Git.pm\n> 261a54ff5b gitweb: removed unused parse_ref method [not posted yet]\n> e9166526a3 Git.pm: add get_type method [not posted yet]\n>\n> The patches marked \"!\" I cannot change without breaking at least one\n> subsequent patch, so every time I want to make a change to one of\n> those, I also need to change at least one subsequent commit, and\n> worse, resubmit it to the mailing list. (E.g. the the recent rename\n> from parse_rev to get_hash necessitated two extra patches to\n> accommodate the change.)\n\nIf the need to cascade changes is about something minor like naming, do\nnot be too picky while you are presenting the progress. I personally\nthink the method for getting the output from rev-parse should be named\nrev_parse and not get_hash, if only not to confuse plumbing users, but do\nnot scramble and rebase -i many patches only because I said so today.\n\nThat will be a waste of your time. Something small like that, I do not\nthink anybody would mind if at the very end of the series there is a patch\nthat modifies all users of get_hash to use rev_parse and rename the\nmethod. I certainly wouldn't.\n\nIf on the other hand the issue is about a design mistake you had in\nearlier patches in the series, well, you may have to re-roll the later\nones to adjust to the interface change _if_ you want to eradicate the\ndesign mistake from the history. But this too depends on the nature of\nthe mistake.\n\nFor example, you may introduce a new sub \"foo\" in commit #1 to support a\nsmall feature or two you add in commit #2 and #3. Later, you would want\nadd yet another new thing that can use something very close to what \"foo\"\nalready does, but realize that you need to call \"foo\" slightly differently\nby giving an additional parameter.\n\nYou might wish that you had a perfect foresight to have that extra\nparameter from the beginning. But _nobody has perfect foresight_. I\nwould not want you to start amending from commit #1 in such a case. Just\nmake commit #4 to be \"Enhance 'foo' to deal with this new situation\", and\nthat commit will change the implementation of \"foo\" and add the necessary\nextra parameter to the existing calling site you introduced in commit #2\nand #3. Then commit #5 will use that new interface to introduce the new\nfeature you needed an enhanced \"foo\" and you go on. Such a case of \"the\nhelper introduced in earlier round was too limited and it is later found\nthat it needs enhancement\" is not even a mistake you would want to remove\nfrom the history. It is just a normal course of code evolution. \n\nKeep your commits small, logically independent steps.\n\nDo not _artificially_ squash the commits --- it is _much worse_ than\nfollowing up with enhancement patches. I think your current patch\ngranularity is quite fine (in good/bad sense not in big/small sense) and\nmakes pleasant read.\n"}]}