Herman van Rink [off-list ref] writes:
quoted
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. :)
quoted
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.
quoted
- 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?
quoted
- 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
On 07/11/2012 06:14 PM, dag@cray.com wrote:
Herman van Rink [off-list ref] writes:
quoted
quoted
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.
quoted
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.
quoted
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.
quoted
quoted
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.
quoted
quoted
- 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?
quoted
quoted
- 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Met vriendelijke groet / Regards,
Herman van Rink
Initfour websolutions