On 07/11/2012 06:14 PM, d...@cray.com wrote: > Herman van Rink <r...@initfour.nl> writes: > >>> It's hard to tell what's what with one big diff. Each command should >>> get its own commit plus more if infrastructure work has to be done. I >>> realize it's a bit of a pain to reformulate this but git rebase -i makes >>> it easy and the history will be much better long-term. >>> >>> Each command should be described briefly in the commit log. >> That would indeed be nice, but as some parts interdependent it would be >> rather complicated. > Do the interdependent parts first, then. These should be pure > infrastructure. > >> And what is the use if their not fully independently testable. > The command should be testable as soon as they are fully implemented, > no? > > I'm thinking about a sequence like this: > > - Infrastructure for command A (and possibly B, C, etc. if they are > interdependent). > - Command A + tests > - Infrastructure for command B > - Command B + tests > - etc. > >> If you want to fake a nice history tree then go ahead, I just don't have >> the energy to go through these commits again just for that. > Well, I can't do this either, both because it would take time to get up > to speed on the patches and because I have a million other things going > on at the moment. So unfortunately, this is going to sit until someone > can take it up. > > Unless Junio accepts your patches, of course. :)
Junio, Could you please consider merging the single commit from my subtree-updates branch? https://github.com/helmo/git/tree/subtree-updates I've seen a few reactions on the git userlist refer to issues which have long been solved in these collected updates. > >>> Some questions/comments: >>> >>> - Is .gittrees the right solution? I like the feature it provides but >>> an external file feels a bit hacky. I wonder if there is a better way >>> to track this metadata. Notes maybe? Other git experts will have to >>> chime in with suggestions. >> It's similar to what git submodule does. And when you add this file to >> the index you can use it on other checkouts as well. > Well, I guess I'm not strongly opposed, I was just asking the question. > >>> - This code seems to be repeated a lot. Maybe it should be a utility >>> function. >> Yes that's there three times... > So you agree it should be factored? > >>> - I removed all this stuff in favor of the test library. Please don't >>> reintroduce it. These new tests will have to be rewritten in terms of >>> the existing test infrastructure. It's not too hard. >> I've left it in to be able to verify your new tests. Once all the new >> tests are passing we can get rid of the old one, not before. >> And as all the old tests are contained in test.sh it should not interfere... > No, I'm very strongly against putting this back in. The new tests will > have to be updated to the upstream test infrastructure. > > -Dave > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Met vriendelijke groet / Regards, Herman van Rink Initfour websolutions -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
