Re: Subtree in Git

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