Herman van Rink <rink@xxxxxxxxxxx> 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. :)
>> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html