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
>> And what is the use if their not fully independently testable.
> The command should be testable as soon as they are fully implemented,
> I'm thinking about a sequence like this:
> - Infrastructure for command A (and possibly B, C, etc. if they are
> - 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
>> 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.
> 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
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