From: Herman van Rink <rink@initfour.nl>
To: Junio C Hamano <gitster@pobox.com>
Cc: dag@cray.com, greened@obbligato.org,
Hilco Wijbenga <hilco.wijbenga@gmail.com>,
Git Users <git@vger.kernel.org>
Subject: Re: Subtree in Git
Date: Sat, 20 Oct 2012 22:03:00 +0200 [thread overview]
Message-ID: <50830374.9090308@initfour.nl> (raw)
In-Reply-To: <nng4npe6zsj.fsf@transit.us.cray.com>
On 07/11/2012 06:14 PM, dag@cray.com wrote:
> 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. :)
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
>>> 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
>
--
Met vriendelijke groet / Regards,
Herman van Rink
Initfour websolutions
next prev parent reply other threads:[~2012-10-20 20:03 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-27 18:48 Subtree in Git Hilco Wijbenga
2012-04-27 20:38 ` dag
2012-04-27 21:09 ` Hilco Wijbenga
2012-05-01 8:34 ` Herman van Rink
2012-05-04 2:26 ` greened
2012-05-04 10:08 ` Herman van Rink
2012-05-05 4:25 ` Junio C Hamano
2012-05-07 15:21 ` dag
2012-05-07 19:50 ` Herman van Rink
2012-05-07 21:57 ` dag
2012-05-11 20:24 ` Junio C Hamano
2012-05-23 15:13 ` dag
2012-06-12 1:30 ` greened
2012-06-13 13:20 ` Herman van Rink
2012-07-11 16:14 ` dag
2012-10-20 20:03 ` Herman van Rink [this message]
2012-10-21 6:32 ` Junio C Hamano
2012-10-21 15:09 ` Herman van Rink
2012-10-21 19:51 ` Junio C Hamano
2012-10-21 20:23 ` Herman van Rink
2012-10-22 14:47 ` dag
2012-10-22 14:44 ` dag
2012-10-22 14:41 ` dag
2012-10-26 13:10 ` Herman van Rink
2012-10-26 13:58 ` David Michael Barr
2012-10-26 16:54 ` James Nylen
2012-10-29 15:55 ` dag
2013-03-01 2:28 ` Kindjal
2013-03-01 22:05 ` Paul Campbell
2013-03-02 11:21 ` David Michael Barr
2013-03-02 17:43 ` Paul Campbell
2013-03-04 22:33 ` Paul Campbell
2012-10-29 15:53 ` dag
2012-05-04 22:50 ` Daniel Koester
2012-06-12 1:32 ` greened
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50830374.9090308@initfour.nl \
--to=rink@initfour.nl \
--cc=dag@cray.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=greened@obbligato.org \
--cc=hilco.wijbenga@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).