Re: Subtree in Git

> Herman van Rink <rink@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.  :)

>
>>> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>