git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Herman van Rink <rink@initfour.nl>
To: greened@obbligato.org
Cc: Junio C Hamano <gitster@pobox.com>,
	Hilco Wijbenga <hilco.wijbenga@gmail.com>,
	Git Users <git@vger.kernel.org>
Subject: Re: Subtree in Git
Date: Wed, 13 Jun 2012 15:20:03 +0200	[thread overview]
Message-ID: <4FD89383.70003@initfour.nl> (raw)
In-Reply-To: <87bokpxqoq.fsf@smith.obbligato.org>

On 12-06-12 03:30, greened@obbligato.org wrote:
> <dag@cray.com> writes:
>
>> <dag@cray.com> writes:
>>
>>>> Its now available as https://github.com/helmo/git/tree/subtree-updates
>>>> The subtree merge version is still available as
>>>> https://github.com/helmo/git/tree/subtree-updates-merged
>>> Cool.  I'll take a look, probably Wednesday at the earliest.
>> Ack.  Sorry, I got sidetracked by home repair issues.  This is still on
>> my radar.  Just wanted to let you know I haven't forgotten.
> Ok, I FINALLY got a look at this (yay!).  Some comments:
>
> Can you put each of these changes in its own commit?
>
>     Collected subtree updates
>     
>     These include:
>      * a .gittrees file with meta data
>      * new sub commands (push-all, pull-all, from-submodule, prune, diff, list)
>      * Documentation updates
>
> 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.
And what is the use if their not fully independently testable.

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.


> 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.

>
>
> +               # this is ugly, but I don't know of a better way to do it. My git-fu is weak.
> +               # git diff-tree expects a treeish, but I have only a repository and branch name.
> +               # I don't know how to turn that into a treeish without creating a remote.
> +               # Please change this if you know a better way!
>
> - Anyone know a better way?  :)
>
>
> +               if [ $# -eq 1 ]; then
> +                       repository=$(git config -f .gittrees subtree.$prefix.url)
> +                       refspec=$1
> +               elif [ $# -eq 2 ]; then
> +                       repository=$1
> +                       refspec=$2
> +               else
> +                       repository=$(git config -f .gittrees subtree.$prefix.url)
> +                       refspec=$(git config -f .gittrees subtree.$prefix.branch)
> +               fi
>
> - This code seems to be repeated a lot.  Maybe it should be a utility
>   function.

Yes that's there three times...
 
>
>
> <more>
> +check_not()
> +{
> +       echo
> +       echo "check: NOT " "$@"
> +       if "$@"; then
> +               echo FAILED
> +               exit 1
> +       else
> +               echo ok
> +               return 0
> +       fi
> +}
> +
> +check_equal()
> +{
> +       echo
> +       echo "check a:" "{$1}"
> +       echo "      b:" "{$2}"
> +       if [ "$1" = "$2" ]; then
> +               return 0
> +       else
> +               echo FAILED
> +               exit 1
> +       fi
> +}
> <more>
>
> - 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...

>
> I like the features introduced here.  The code and tests need a bit of
> cleanup and they really should be split into multiple commits.
>
> Thanks for working on this!
>
>                                    -Dave
>


-- 
Met vriendelijke groet / Regards,

Herman van Rink 
Initfour websolutions

  reply	other threads:[~2012-06-13 13:20 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 [this message]
2012-07-11 16:14                   ` dag
2012-10-20 20:03                     ` Herman van Rink
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=4FD89383.70003@initfour.nl \
    --to=rink@initfour.nl \
    --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).