Subtree in Git

Subtree in Git

[Hilco Wijbenga]

Hi all,

Do we have an idea of when subtree support will be a part of Git core?
I am aware that I can install it separately but I'd like to know if
there is something like a timeline or a target Git version number. And
"no", is fine. :-)

Cheers,
Hilco

Re: Subtree in Git

[dag]

Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:

> Do we have an idea of when subtree support will be a part of Git core?
> I am aware that I can install it separately but I'd like to know if
> there is something like a timeline or a target Git version number. And
> "no", is fine. :-)

We don't know right now.  I want to take a look at Herman's patches
first but have been delayed for various reasons.  I hope to get to that
this weekend.  I also want to get at least one release under our belt.

                             -Dave

Re: Subtree in Git

[Hilco Wijbenga]

On 27 April 2012 13:38,  <dag@cray.com> wrote:
> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>
>> Do we have an idea of when subtree support will be a part of Git core?
>> I am aware that I can install it separately but I'd like to know if
>> there is something like a timeline or a target Git version number. And
>> "no", is fine. :-)
>
> We don't know right now.  I want to take a look at Herman's patches
> first but have been delayed for various reasons.  I hope to get to that
> this weekend.  I also want to get at least one release under our belt.

I pretty much expected that. :-) Good luck!

No worries, I've just installed the latest Subtree from contrib/ so I
can play with it. I just don't want to rely on Subtree until I no
longer have to tell everyone to install it separately. That's just not
going to fly. :-)

Re: Subtree in Git

[Herman van Rink]

On 27-04-12 22:38, dag@cray.com wrote:
> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>
>> Do we have an idea of when subtree support will be a part of Git core?
>> I am aware that I can install it separately but I'd like to know if
>> there is something like a timeline or a target Git version number. And
>> "no", is fine. :-)
> We don't know right now.  I want to take a look at Herman's patches
> first but have been delayed for various reasons.  I hope to get to that
> this weekend.  I also want to get at least one release under our belt.

I've worked on this a bit over the weekend.

I've forked the main git repo  on github to merge my tree on top of that.

I basically did a: git subtree merge --prefix=contrib/subtree <my
git-subtree branch>

The work in progress in on: https://github.com/helmo/git (the
subtree-updates branch)

Rentzsch supplied a patch to get the original test.sh up and running again.
This will make it easier to get the tests in t7900-subtree.sh updated.

-- 
Met vriendelijke groet / Regards,

Herman van Rink 
Initfour websolutions

Re: Subtree in Git

[greened]

Herman van Rink <rink@initfour.nl> writes:

>> We don't know right now.  I want to take a look at Herman's patches
>> first but have been delayed for various reasons.  I hope to get to that
>> this weekend.  I also want to get at least one release under our belt.
>
> I've worked on this a bit over the weekend.
>
> I've forked the main git repo  on github to merge my tree on top of that.
>
> I basically did a: git subtree merge --prefix=contrib/subtree <my
> git-subtree branch>
>
> The work in progress in on: https://github.com/helmo/git (the
> subtree-updates branch)

This branch seems to have a bunch of commits from master or some other
branch:

on master:
git log subtree-updates --not HEAD

[...some git-subtree stuff...]
commit 10d4332e007132a38dc61f03c760d355da5cd550
Author: Junio C Hamano <gitster@pobox.com>
Date:   Sun Apr 29 18:00:47 2012 -0700

    The seventh batch of topics graduated to 'master'
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit a75aba4a5306d0fee6a8ee8b48943e2c19eb2750
Merge: 55375e9 46e3581
Author: Junio C Hamano <gitster@pobox.com>
Date:   Sun Apr 29 17:52:02 2012 -0700

    Merge branch 'js/daemon-test-race-fix'
[...]

Perhaps I'm doing something wrong.  Or does the subtree-updates branch
need to be refreshed?

                               -Dave

Re: Subtree in Git

[Herman van Rink]

On 04-05-12 04:26, greened@obbligato.org wrote:
> Herman van Rink <rink@initfour.nl> writes:
>
>>> We don't know right now.  I want to take a look at Herman's patches
>>> first but have been delayed for various reasons.  I hope to get to that
>>> this weekend.  I also want to get at least one release under our belt.
>> I've worked on this a bit over the weekend.
>>
>> I've forked the main git repo  on github to merge my tree on top of that.
>>
>> I basically did a: git subtree merge --prefix=contrib/subtree <my
>> git-subtree branch>
>>
>> The work in progress in on: https://github.com/helmo/git (the
>> subtree-updates branch)
> This branch seems to have a bunch of commits from master or some other
> branch:
>
> on master:
> git log subtree-updates --not HEAD
>
> [...some git-subtree stuff...]
> commit 10d4332e007132a38dc61f03c760d355da5cd550
> Author: Junio C Hamano <gitster@pobox.com>
> Date:   Sun Apr 29 18:00:47 2012 -0700
>
>     The seventh batch of topics graduated to 'master'
>     
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> commit a75aba4a5306d0fee6a8ee8b48943e2c19eb2750
> Merge: 55375e9 46e3581
> Author: Junio C Hamano <gitster@pobox.com>
> Date:   Sun Apr 29 17:52:02 2012 -0700
>
>     Merge branch 'js/daemon-test-race-fix'
> [...]
>
> Perhaps I'm doing something wrong.  Or does the subtree-updates branch
> need to be refreshed?

Strange, I did fork the git/git repo on April 29 though.
As far as I know I branched from master and merged the subtree stuff
ontop of that.

I've now merged master, fixed some whitespace and pushed my
subtree-updates branch again.

And I get a nice diff from: git diff gitgit/master..subtree-updates

-- 
Met vriendelijke groet / Regards,

Herman van Rink 
Initfour websolutions

Re: Subtree in Git

[Junio C Hamano]

greened@obbligato.org writes:

>> I basically did a: git subtree merge --prefix=contrib/subtree <my
>> git-subtree branch>
>>
>> The work in progress in on: https://github.com/helmo/git (the
>> subtree-updates branch)
>
> This branch seems to have a bunch of commits from master or some other
> branch:

Isn't the confusing shape of the history a direct result of what Herman
said he did above, i.e. use of "subtree merge"?  I thought that we agreed
not to do any more subtree merges for further updates when we slurped the
subtree history to contrib/ early in this cycle, so if that is the case,
Herman needs to rebase his work so that the integration will not need any
"subtree merge" into git.git, perhaps?

I looked at various branches found with ls-remote in that repository but I
couldn't quite tell which is what, with too many cross merges, among which
there are unnecessary duplicated commits (e.g. 90275824 and b9a745f7 seems
to be two equivalent commits) and questionable changes from the overall
project's point of view.

For example, it renames git-subtree.txt to README.md at a4416ee; while I
find the idea of departing from asciidoc somewhat attractive (perhaps this
is only because I haven't been burned by markdown yet), if "git subtree"
wants to live in the git.git repository, that change is a regression.
Later the file is renamed back to git-subtree.txt (README.md is lost) at
9ffdeb, a commit with a single-liner "fixing typo" log message adds the
README.md file with full contents of git-subtree.txt again at d9ccd03b,
and then later merge of the branch at 8861de28 finally decides to revert
that to have a shorter README.md that the history originally had, or
something.  In short, it is a mess.

Not very impressed, but I have this suspition that the history I was
looking at was not what was meant to be sent to me and an older
incarnation of the project before Herman cleaned it up for public
consumption, or something.

Confused...

Re: Subtree in Git

[dag]

Junio C Hamano <gitster@pobox.com> writes:

>> This branch seems to have a bunch of commits from master or some other
>> branch:
>
> Isn't the confusing shape of the history a direct result of what Herman
> said he did above, i.e. use of "subtree merge"?  I thought that we agreed
> not to do any more subtree merges for further updates when we slurped the
> subtree history to contrib/ early in this cycle, so if that is the case,
> Herman needs to rebase his work so that the integration will not need any
> "subtree merge" into git.git, perhaps?

I think you're right.

> In short, it is a mess.

I agree.  I think Herman is working to fix it.  A rebase and rework of
the patch set would be very helpful.

> Not very impressed, but I have this suspition that the history I was
> looking at was not what was meant to be sent to me and an older
> incarnation of the project before Herman cleaned it up for public
> consumption, or something.

That's the impression I got as well.

I haven't had a chance to look at Herman's latest tree.

                            -Dave

Re: Subtree in Git

[Herman van Rink]

On 05/05/2012 06:25 AM, Junio C Hamano wrote:
> greened@obbligato.org writes:
>
>>> I basically did a: git subtree merge --prefix=contrib/subtree <my
>>> git-subtree branch>
>>>
>>> The work in progress in on: https://github.com/helmo/git (the
>>> subtree-updates branch)
>> This branch seems to have a bunch of commits from master or some other
>> branch:
> Isn't the confusing shape of the history a direct result of what Herman
> said he did above, i.e. use of "subtree merge"?  I thought that we agreed
> not to do any more subtree merges for further updates when we slurped the
> subtree history to contrib/ early in this cycle, so if that is the case,
> Herman needs to rebase his work so that the integration will not need any
> "subtree merge" into git.git, perhaps?
>
> I looked at various branches found with ls-remote in that repository but I
> couldn't quite tell which is what, with too many cross merges, among which
> there are unnecessary duplicated commits (e.g. 90275824 and b9a745f7 seems
> to be two equivalent commits) and questionable changes from the overall
> project's point of view.
>
> For example, it renames git-subtree.txt to README.md at a4416ee; while I
> find the idea of departing from asciidoc somewhat attractive (perhaps this
> is only because I haven't been burned by markdown yet), if "git subtree"
> wants to live in the git.git repository, that change is a regression.
> Later the file is renamed back to git-subtree.txt (README.md is lost) at
> 9ffdeb, a commit with a single-liner "fixing typo" log message adds the
> README.md file with full contents of git-subtree.txt again at d9ccd03b,
> and then later merge of the branch at 8861de28 finally decides to revert
> that to have a shorter README.md that the history originally had, or
> something.  In short, it is a mess.
>
> Not very impressed, but I have this suspition that the history I was
> looking at was not what was meant to be sent to me and an older
> incarnation of the project before Herman cleaned it up for public
> consumption, or something.
>
> Confused...

I agree that it's a messy history.  It the result of the many painful
merges I did. In various stages a conflicting indentation and other
changes made it painful to get a clean merge.
In an attempt to get through this in a pragmatic way the history has
taken some damage.

Before  starting this latest subtree merge I actually tried to rebase.
However this failed very quickly, on the I think third commit out of 60,
landing me in conflict resolution as I had already been through.
I'd love to improve git but this was just taking too mush effort.
When I saw the quick result from subtree merge that seemed like a good
thing.

Wouldn't a good rebase have almost just as messy a history as the
subtree merge?

As an alternative I've now applied a patch with all changes on a clean
master branch.
In the commit message I've named all committers from the original history.
Would that be acceptable?
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

-- 

Met vriendelijke groet / Regards,

Herman van Rink
Initfour websolutions

Re: Subtree in Git

[dag]

Herman van Rink <rink@initfour.nl> writes:

> As an alternative I've now applied a patch with all changes on a clean
> master branch.
> In the commit message I've named all committers from the original history.
> Would that be acceptable?

Seems ok to me but Junio has the final say.

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

                            -Dave

Re: Subtree in Git

[Junio C Hamano]

<dag@cray.com> writes:

> Herman van Rink <rink@initfour.nl> writes:
>
>> As an alternative I've now applied a patch with all changes on a clean
>> master branch.
>> In the commit message I've named all committers from the original history.
>> Would that be acceptable?
>
> Seems ok to me but Junio has the final say.

What we do *not* want to see are merges from commits after the "subtree"
stuff is moved down to "contrib/subtree" into commits before the merge
happened, as that would mean "constant renaming merge" mess in the history
(see http://article.gmane.org/gmane.comp.version-control.git/197689 as
well).

If it is too much trouble to clean up the history, it is OK to leave
"oops, an earlier one was a total mistake but it is too late to rewind the
tree, so here is a fixup" commits.  At the very least, however, it should
be possible to clean up the history to pretend that everything has
happened _after_ the "git-subtree" project transitioned to have its files
under "contrib/subtree" hierarchy in preparation for eventually becoming a
part of the core git, no?  Then the back-merges from your tree to Herman's
will be merging updates to contrib/subtree part into contrib/subtree part,
and "git log contrib/subtree" will give us a readable output.

I thought "subtree" was a tool to make it very easy to let you pretend
that everything happened in the context of containing larger tree when you
wanted to, so I am hoping that is not asking too much (even a subtree
unaware "filter-branch" should be able to do that kind of thing, I would
think).

Thanks.

Re: Subtree in Git

[dag]

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

                             -Dave

Re: Subtree in Git

[greened]

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

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.


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


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

Re: Subtree in Git

[Herman van Rink]

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

Re: Subtree in Git

[dag]

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

Re: Subtree in Git

[Herman van Rink]

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

Re: Subtree in Git

[Junio C Hamano]

Herman van Rink <rink@initfour.nl> writes:

> Junio, Could you please consider merging the single commit from my
> subtree-updates branch? https://github.com/helmo/git/tree/subtree-updates

In general, in areas like contrib/ where there is a volunteer area
maintainer, unless the change something ultra-urgent (e.g. serious
security fix) and the area maintainer is unavailable, I'm really
reluctant to bypass and take a single patch that adds many things
that are independent from each other.

Especially not immediately before tagging 1.8.0 final.

Re: Subtree in Git

[Herman van Rink]

On 10/21/2012 08:32 AM, Junio C Hamano wrote:
> Herman van Rink <rink@initfour.nl> writes:
>
>> Junio, Could you please consider merging the single commit from my
>> subtree-updates branch? https://github.com/helmo/git/tree/subtree-updates
> In general, in areas like contrib/ where there is a volunteer area
> maintainer, unless the change something ultra-urgent (e.g. serious
> security fix) and the area maintainer is unavailable, I'm really
> reluctant to bypass and take a single patch that adds many things
> that are independent from each other.

Who do you see as volunteer area maintainer for contrib/subtree?
My best guess would be Dave. And he already indicated earlier in the
thread to be ok with the combined patch as long as you are ok with it.

>
> Especially not immediately before tagging 1.8.0 final.

Sure, we've waited this long... I don't mind waiting one more release cycle.

-- 

Met vriendelijke groet / Regards,

Herman van Rink
Initfour websolutions

Re: Subtree in Git

[Junio C Hamano]

Herman van Rink <rink@initfour.nl> writes:

> On 10/21/2012 08:32 AM, Junio C Hamano wrote:
>> Herman van Rink <rink@initfour.nl> writes:
>>
>>> Junio, Could you please consider merging the single commit from my
>>> subtree-updates branch? https://github.com/helmo/git/tree/subtree-updates
>> In general, in areas like contrib/ where there is a volunteer area
>> maintainer, unless the change something ultra-urgent (e.g. serious
>> security fix) and the area maintainer is unavailable, I'm really
>> reluctant to bypass and take a single patch that adds many things
>> that are independent from each other.
>
> Who do you see as volunteer area maintainer for contrib/subtree?
> My best guess would be Dave. And he already indicated earlier in the
> thread to be ok with the combined patch as long as you are ok with it.

Yes, dag volunteered to be the area maintainer to act as a
gatekeeper for me.

The message you addressed to me was sent as a response to his
message, where he gave you specific suggestions to improve the patch
and turn it into a readable series instead of a single ball of wax
and it looked to me as if you are trying to bypass him and shove the
single ball of wax to our history over his objection.

I haven't formed an opinion on the particular change as to how bad
its collapsing unrelated changes into a single change is. Maybe they
are not as unrelated and form a coherent whole.  Maybe not.  Also I
personally do not mind too much if the area maintainer for contrib/
has a lower standard for atomicity of commits compared to the rest
of the system.  But I do prefer the decision to be made at the level
of area maintainer's, and have issues when people try to bypass
without a good reason.

Note that I was not following the thread very closely, so I may have
misread the discussion.  I read his "Unless Junio accepts..." to
mean "I (dag) still object, but if Junio accepts that patch I object
to directly, there is nothing I can do about it".  That is very
different from "I am on the fence and cannot decide it is a good
patch or not.  I'll let Junio decide; I am OK as long as he is".

Thanks.

Re: Subtree in Git

[Herman van Rink]

On 10/21/2012 09:51 PM, Junio C Hamano wrote:
> Herman van Rink <rink@initfour.nl> writes:
>
>> On 10/21/2012 08:32 AM, Junio C Hamano wrote:
>>> Herman van Rink <rink@initfour.nl> writes:
>>>
>>>> Junio, Could you please consider merging the single commit from my
>>>> subtree-updates branch? https://github.com/helmo/git/tree/subtree-updates
>>> In general, in areas like contrib/ where there is a volunteer area
>>> maintainer, unless the change something ultra-urgent (e.g. serious
>>> security fix) and the area maintainer is unavailable, I'm really
>>> reluctant to bypass and take a single patch that adds many things
>>> that are independent from each other.
>> Who do you see as volunteer area maintainer for contrib/subtree?
>> My best guess would be Dave. And he already indicated earlier in the
>> thread to be ok with the combined patch as long as you are ok with it.
> Yes, dag volunteered to be the area maintainer to act as a
> gatekeeper for me.
>
> The message you addressed to me was sent as a response to his
> message, where he gave you specific suggestions to improve the patch
> and turn it into a readable series instead of a single ball of wax
> and it looked to me as if you are trying to bypass him and shove the
> single ball of wax to our history over his objection.
>
> I haven't formed an opinion on the particular change as to how bad
> its collapsing unrelated changes into a single change is. Maybe they
> are not as unrelated and form a coherent whole.  Maybe not.  Also I
> personally do not mind too much if the area maintainer for contrib/
> has a lower standard for atomicity of commits compared to the rest
> of the system.  But I do prefer the decision to be made at the level
> of area maintainer's, and have issues when people try to bypass
> without a good reason.
>
> Note that I was not following the thread very closely, so I may have
> misread the discussion.  I read his "Unless Junio accepts..." to
> mean "I (dag) still object, but if Junio accepts that patch I object
> to directly, there is nothing I can do about it".  That is very
> different from "I am on the fence and cannot decide it is a good
> patch or not.  I'll let Junio decide; I am OK as long as he is".
>
> Thanks.

Thanks for explaining.
I had read it the latter way.

The problem is that I don't have the time to split all these out. Dag
has indicated that he does not have the time either.

This single ball of wax was already an alternative to the 'messy' merge
history it had accumulated. The result of merging from dozens of github
forks with numerous levels of parallel/contra-productive whitspace fixes.

Dag: Did I read it correctly?

-- 

Met vriendelijke groet / Regards,

Herman van Rink
Initfour websolutions

Re: Subtree in Git

[dag]

Herman van Rink <rink@initfour.nl> writes:

> The problem is that I don't have the time to split all these out. Dag
> has indicated that he does not have the time either.

I would have the time to review and integrate separate patches.  I do
not have time to unwrap the ball of wax and ensure the quality of each
feature and bug fix.  That is the responsibility of the submitter.  You
can't expect reviewers to do your work for you.  I'm not being harsh, it
is simply the reality of how things work in every project I've been
involved with.

> This single ball of wax was already an alternative to the 'messy' merge
> history it had accumulated. The result of merging from dozens of github
> forks with numerous levels of parallel/contra-productive whitspace fixes.

Yes, we don't really want that history.  You have a single patch now.  A
series of git rebase -i + git add -i should make it easy to separate it
into patches for each feature and bug fix, as I suggested previously.

It really, really shouldn't be that hard unless the code is atrocious.

                            -David

Re: Subtree in Git

[dag]

Junio C Hamano <gitster@pobox.com> writes:

> I haven't formed an opinion on the particular change as to how bad
> its collapsing unrelated changes into a single change is. Maybe they
> are not as unrelated and form a coherent whole.  Maybe not.  

It is difficult for me to tell which is one of the red flags that caused
me to request breaking it up.  It's much to hard to review this patch as
it is.  It conflates multiple features and bug fixes.  It includes
comments to the effect of, "I don't like this but I don't know of a
better way."  Part of the reson we do reviews is to have people help out
and find a better way.  I don't think people can do that with the way
the patch is currently structured.

> Note that I was not following the thread very closely, so I may have
> misread the discussion.  I read his "Unless Junio accepts..." to
> mean "I (dag) still object, but if Junio accepts that patch I object
> to directly, there is nothing I can do about it".  That is very
> different from "I am on the fence and cannot decide it is a good
> patch or not.  I'll let Junio decide; I am OK as long as he is".

Yopur first reading is the correct one.

                              -David

Re: Subtree in Git

[dag]

Herman van Rink <rink@initfour.nl> writes:

> On 10/21/2012 08:32 AM, Junio C Hamano wrote:
>> Herman van Rink <rink@initfour.nl> writes:
>>
>>> Junio, Could you please consider merging the single commit from my
>>> subtree-updates branch? https://github.com/helmo/git/tree/subtree-updates
>> In general, in areas like contrib/ where there is a volunteer area
>> maintainer, unless the change something ultra-urgent (e.g. serious
>> security fix) and the area maintainer is unavailable, I'm really
>> reluctant to bypass and take a single patch that adds many things
>> that are independent from each other.
>
> Who do you see as volunteer area maintainer for contrib/subtree?
> My best guess would be Dave. And he already indicated earlier in the
> thread to be ok with the combined patch as long as you are ok with it.

Let's be clear.  Junio owns the project so what he says goes, no
question.  I provided some review feedback which I thought would help
the patches get in more easily.  We really shouldn't be adding multiple
features in one patch.  This is easily separated into multiple patches.

Then there is the issue of testcases.  We should NOT have git-subtree go
back to the pre-merge _ad_hoc_ test environment.  We should use what the
usptream project uses.  That will make mainlining this much easier in
the future.

If Junio is ok with overriding my decisions here, that's fine.  But I
really don't understand why you are so hesitant to rework the patches
when it should be realtively easy.  Certainly easier than convincing me
they are in good shape currently.  :)

                            -David

Re: Subtree in Git

[Herman van Rink]

On 10/22/2012 04:41 PM, dag@cray.com wrote:
> Herman van Rink <rink@initfour.nl> writes:
>
>> On 10/21/2012 08:32 AM, Junio C Hamano wrote:
>>> Herman van Rink <rink@initfour.nl> writes:
>>>
>>>> Junio, Could you please consider merging the single commit from my
>>>> subtree-updates branch? https://github.com/helmo/git/tree/subtree-updates
>>> In general, in areas like contrib/ where there is a volunteer area
>>> maintainer, unless the change something ultra-urgent (e.g. serious
>>> security fix) and the area maintainer is unavailable, I'm really
>>> reluctant to bypass and take a single patch that adds many things
>>> that are independent from each other.
>> Who do you see as volunteer area maintainer for contrib/subtree?
>> My best guess would be Dave. And he already indicated earlier in the
>> thread to be ok with the combined patch as long as you are ok with it.
> Let's be clear.  Junio owns the project so what he says goes, no
> question.  I provided some review feedback which I thought would help
> the patches get in more easily.  We really shouldn't be adding multiple
> features in one patch.  This is easily separated into multiple patches.
>
> Then there is the issue of testcases.  We should NOT have git-subtree go
> back to the pre-merge _ad_hoc_ test environment.  We should use what the
> usptream project uses.  That will make mainlining this much easier in
> the future.
>
> If Junio is ok with overriding my decisions here, that's fine.  But I
> really don't understand why you are so hesitant to rework the patches
> when it should be realtively easy.  Certainly easier than convincing me
> they are in good shape currently.  :)

If it's so easy to rework these patches then please do so yourself.
It's been ages since I've worked on this so I would also have to
re-discover everything.

And yes it's ugly, but so is the code that you've merged in.
Which you haven't changed a single line in after merging. So it's still
the version from Avery which hasn't been maintained for the last two years.

This ball of wax is still a big improvement in my opinion.

Feel free to scrape the github forks for improvements on your own,
cleanup the code style and create fitting test cases.
But if you intend on taking in changes only when presented to you on a
silver patter, then we're better of with subtree removed from the
contrib tree.

What would a random user have to do to get a patch in? I've found a
number of subtree related mails on the git-user list go completely
unanswerd.
Amongst them a patch from James Nylen wich seems very reasonable.

-- 

Met vriendelijke groet / Regards,

Herman van Rink
Initfour websolutions

Re: Subtree in Git

[David Michael Barr]

On Saturday, 27 October 2012 at 12:10 AM, Herman van Rink wrote:
> On 10/22/2012 04:41 PM, dag@cray.com (mailto:dag@cray.com) wrote:
> > Herman van Rink <rink@initfour.nl (mailto:rink@initfour.nl)> writes:
> > 
> > > On 10/21/2012 08:32 AM, Junio C Hamano wrote:
> > > > Herman van Rink <rink@initfour.nl (mailto:rink@initfour.nl)> writes:
> > > > 
> > > > > Junio, Could you please consider merging the single commit from my
> > > > > subtree-updates branch? https://github.com/helmo/git/tree/subtree-updates
> > > > 
> > > > 
> > > > In general, in areas like contrib/ where there is a volunteer area
> > > > maintainer, unless the change something ultra-urgent (e.g. serious
> > > > security fix) and the area maintainer is unavailable, I'm really
> > > > reluctant to bypass and take a single patch that adds many things
> > > > that are independent from each other.
> > > 
> > > 
> > > Who do you see as volunteer area maintainer for contrib/subtree?
> > > My best guess would be Dave. And he already indicated earlier in the
> > > thread to be ok with the combined patch as long as you are ok with it.
> > 
> > 
> > Let's be clear. Junio owns the project so what he says goes, no
> > question. I provided some review feedback which I thought would help
> > the patches get in more easily. We really shouldn't be adding multiple
> > features in one patch. This is easily separated into multiple patches.
> > 
> > Then there is the issue of testcases. We should NOT have git-subtree go
> > back to the pre-merge _ad_hoc_ test environment. We should use what the
> > usptream project uses. That will make mainlining this much easier in
> > the future.
> > 
> > If Junio is ok with overriding my decisions here, that's fine. But I
> > really don't understand why you are so hesitant to rework the patches
> > when it should be realtively easy. Certainly easier than convincing me
> > they are in good shape currently. :)
> 
> 
> 
> If it's so easy to rework these patches then please do so yourself.
> It's been ages since I've worked on this so I would also have to
> re-discover everything.

>From a quick survey, it appears there are no more than 55 patches
squashed into the submitted patch.
As I have an interest in git-subtree for maintaining the out-of-tree
version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
to make some sense of the organic growth that happened on GitHub.
It doesn't appear that anyone else is willing to do this, so I doubt
there will be any duplication of effort.



--
David Michael Barr

Re: Subtree in Git

[James Nylen]

On Fri, Oct 26, 2012 at 9:58 AM, David Michael Barr <b@rr-dav.id.au> wrote:
> From a quick survey, it appears there are no more than 55 patches
> squashed into the submitted patch.
> As I have an interest in git-subtree for maintaining the out-of-tree
> version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
> to make some sense of the organic growth that happened on GitHub.
> It doesn't appear that anyone else is willing to do this, so I doubt
> there will be any duplication of effort.

David, I think that would be great.  I wish I had time to work on
unwrapping the current patch but I don't.  I will definitely re-submit
my (simple) patch after this is done though.

Re: Subtree in Git

[dag]

David Michael Barr <b@rr-dav.id.au> writes:

> As I have an interest in git-subtree for maintaining the out-of-tree
> version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
> to make some sense of the organic growth that happened on GitHub.
> It doesn't appear that anyone else is willing to do this, so I doubt
> there will be any duplication of effort.

Go for it!  Thanks!

                      -David

Re: Subtree in Git

[Kindjal]

David Michael Barr <b <at> rr-dav.id.au> writes:
 
> From a quick survey, it appears there are no more than 55 patches
> squashed into the submitted patch.
> As I have an interest in git-subtree for maintaining the out-of-tree
> version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
> to make some sense of the organic growth that happened on GitHub.
> It doesn't appear that anyone else is willing to do this, so I doubt
> there will be any duplication of effort.
> 

What is the status of the work on git-subtree described in this thread?
It looks like it's stalled.

Re: Subtree in Git

[Paul Campbell]

On Fri, Mar 1, 2013 at 2:28 AM, Kindjal <kindjal@gmail.com> wrote:
> David Michael Barr <b <at> rr-dav.id.au> writes:
>
>> From a quick survey, it appears there are no more than 55 patches
>> squashed into the submitted patch.
>> As I have an interest in git-subtree for maintaining the out-of-tree
>> version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
>> to make some sense of the organic growth that happened on GitHub.
>> It doesn't appear that anyone else is willing to do this, so I doubt
>> there will be any duplication of effort.
>>
>
> What is the status of the work on git-subtree described in this thread?
> It looks like it's stalled.
>

I hadn't been aware of that patch. Reading the thread David Michael
Barr was going to try picking the patch apart into sensible chunks.

My own patches, some of which I've submitted to the list, appear to be
tackling a couple of the same things (e.g. storing subtree metadata in
an ini file). Mine can be found here
(https://github.com/kemitix/git/commits/subtree-usability), including
some I've not submitted yet.

If this work is still needing done I'd like to volunteer.

-- 
Paul [W] Campbell

Re: Subtree in Git

[David Michael Barr]

On Sat, Mar 2, 2013 at 9:05 AM, Paul Campbell <pcampbell@kemitix.net> wrote:
> On Fri, Mar 1, 2013 at 2:28 AM, Kindjal <kindjal@gmail.com> wrote:
>> David Michael Barr <b <at> rr-dav.id.au> writes:
>>
>>> From a quick survey, it appears there are no more than 55 patches
>>> squashed into the submitted patch.
>>> As I have an interest in git-subtree for maintaining the out-of-tree
>>> version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
>>> to make some sense of the organic growth that happened on GitHub.
>>> It doesn't appear that anyone else is willing to do this, so I doubt
>>> there will be any duplication of effort.
>>>
>>
>> What is the status of the work on git-subtree described in this thread?
>> It looks like it's stalled.
>>
>
> I hadn't been aware of that patch. Reading the thread David Michael
> Barr was going to try picking the patch apart into sensible chunks.
>

Sorry for not updating the thread. I did end up moving onto other things.
I quickly realised the reason for globbing all the patches together was
that the individual patches were not well contained.
That is single patches with multiple unrelated changes and multiple
patches changing the same things in different directions.
To me this means that the first step is to curate the history.

> If this work is still needing done I'd like to volunteer.

You're most welcome. Sorry again for abandoning the thread.

--
David Michael Barr

Re: Subtree in Git

[Paul Campbell]

On Sat, Mar 2, 2013 at 11:21 AM, David Michael Barr <b@rr-dav.id.au> wrote:
> On Sat, Mar 2, 2013 at 9:05 AM, Paul Campbell <pcampbell@kemitix.net> wrote:
>> On Fri, Mar 1, 2013 at 2:28 AM, Kindjal <kindjal@gmail.com> wrote:
>>> David Michael Barr <b <at> rr-dav.id.au> writes:
>>>
>>>> From a quick survey, it appears there are no more than 55 patches
>>>> squashed into the submitted patch.
>>>> As I have an interest in git-subtree for maintaining the out-of-tree
>>>> version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
>>>> to make some sense of the organic growth that happened on GitHub.
>>>> It doesn't appear that anyone else is willing to do this, so I doubt
>>>> there will be any duplication of effort.
>>>>
>>>
>>> What is the status of the work on git-subtree described in this thread?
>>> It looks like it's stalled.
>>>
>>
>> I hadn't been aware of that patch. Reading the thread David Michael
>> Barr was going to try picking the patch apart into sensible chunks.
>>
>
> Sorry for not updating the thread. I did end up moving onto other things.
> I quickly realised the reason for globbing all the patches together was
> that the individual patches were not well contained.
> That is single patches with multiple unrelated changes and multiple
> patches changing the same things in different directions.
> To me this means that the first step is to curate the history.
>
>> If this work is still needing done I'd like to volunteer.
>
> You're most welcome. Sorry again for abandoning the thread.
>
> --
> David Michael Barr

Okay, I'll start picking the patch apart this week then feedback when
I have a plan to tackle it all.

-- 
Paul [W] Campbell

Re: Subtree in Git

[Paul Campbell]

On Sat, Mar 2, 2013 at 5:43 PM, Paul Campbell <pcampbell@kemitix.net> wrote:
> On Sat, Mar 2, 2013 at 11:21 AM, David Michael Barr <b@rr-dav.id.au> wrote:
>> On Sat, Mar 2, 2013 at 9:05 AM, Paul Campbell <pcampbell@kemitix.net> wrote:
>>> On Fri, Mar 1, 2013 at 2:28 AM, Kindjal <kindjal@gmail.com> wrote:
>>>> David Michael Barr <b <at> rr-dav.id.au> writes:
>>>>
>>>>> From a quick survey, it appears there are no more than 55 patches
>>>>> squashed into the submitted patch.
>>>>> As I have an interest in git-subtree for maintaining the out-of-tree
>>>>> version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
>>>>> to make some sense of the organic growth that happened on GitHub.
>>>>> It doesn't appear that anyone else is willing to do this, so I doubt
>>>>> there will be any duplication of effort.
>>>>>
>>>>
>>>> What is the status of the work on git-subtree described in this thread?
>>>> It looks like it's stalled.
>>>>
>>>
>>> I hadn't been aware of that patch. Reading the thread David Michael
>>> Barr was going to try picking the patch apart into sensible chunks.
>>>
>>
>> Sorry for not updating the thread. I did end up moving onto other things.
>> I quickly realised the reason for globbing all the patches together was
>> that the individual patches were not well contained.
>> That is single patches with multiple unrelated changes and multiple
>> patches changing the same things in different directions.
>> To me this means that the first step is to curate the history.
>>
>>> If this work is still needing done I'd like to volunteer.
>>
>> You're most welcome. Sorry again for abandoning the thread.
>>
>> --
>> David Michael Barr
>
> Okay, I'll start picking the patch apart this week then feedback when
> I have a plan to tackle it all.
>
> --
> Paul [W] Campbell

>From a comparison of the tip for helmo's subtree-updates branch and
the current master these are the changes and features that the patch
is providing.  I've listed the changes briefly per file, with a note
of the general action I plan to take. This is based on a simple diff,
so some changes are actually reversions to recent commits, which I
have tried to note.

Makefile

	* Regresses two recent commits (8165be064e and d86848228f)
	* ACTION: Ignore file

README.md

	* Adds a markdown readme file (that github likes to have in root)
	* Includes some install instructions in a pseudo man page format
	* The INSTALL file covers all the information contained and is more up-to-date
	* ACTION: Ignore file

git-subtree.sh

	* OPTS_SPEC
		* pull/push: options for repository and refspec are both optional,
[<repository> [<refspec>]]
		* new sub-command: pull-all
		* new sub-command: push-all
		* new sub-command: list
		* new sub-command: from-submodule
		* new sub-command: prune
		* new sub-command: diff
		* new option for push: --force
	* Trailing slash on prefix is removed
	* Different pretty log format in cmd_commit getting piped to set some
environment variables
		* Would revert: a5b8e28e4e
		* Ignoring this change
	* Removes all tests in cmd_add to check that refspec is valid
		* I've posted a patch with new tests to the list recently that would
go in here
	* Change reference to 'commit' into 'refspec' in error message in cmd_add
	* Stores subtree metadata in .gittrees as:
		[subtree "$dir"]
			url = $repository
			path = $dir
			branch = $refspec
	* Inadvertently commited a change to the linefeed character in
cmd_split for the activity indicator
	* cmd_pull/cmd_push: reads options from .gitrees if not provided on
the command line
	* Implementation of cmd_diff
		* fetches remote repo as a temporary git-remote then uses
git-diff-tree to compare before removing the temporary git-remote
	* Implementation of cmd_list as plain wrapper to new functions subtree_list
		* Iterates over subtrees listed in .gittrees and prints out their details
		* Dubious about greps used to get list from .gittrees
	* Implementation of cmd_from-submodule
		* Converts a git-submodule into a git-subtree
	* Implementation of cmd_prune
		* Removes entries from .gittrees where the $dir is missing
		* Dubious about greps used to get list from .gittrees
	* Implementation of cmd_pull-all
		* Performs a git-subtree pull for each subtree
		* Dubious about greps used to get list from .gittrees
	* Implementation of cmd_push-all
		* Perfroms a git-subtree push for each subtree
		* Dubious about greps used to get list from .gittrees

git-subtree.txt

	* Adds brief descriptions for commands:
		* pull-all
		* push-all
		* list
		* from-submodule
		* prune
		* diff ("TO BE DOCUMENTED")
	* Notes optional -f|--force for push sub-command
	* fixes a typo in text for Example 1 (s/incldued/included/)

t/t7900.sh

	* Add numeric comments for each test
		* recently removed (144797d720) in master so don't add them back
	* ACTION: Ignore file

test.sh

	* Legacy tests
	* ACTION: Ignore file

My next step will be to find the commits (from helmo's
subtree-updates-merged branch) that provide the features above that I
want to keep and cherry-pick them into a new branch (or two).

-- 
Paul [W] Campbell

Re: Subtree in Git

[dag]

Herman van Rink <rink@initfour.nl> writes:

> What would a random user have to do to get a patch in? I've found a
> number of subtree related mails on the git-user list go completely
> unanswerd.  Amongst them a patch from James Nylen wich seems very
> reasonable.

I have those patches queued for merging.  I've been out of town and
otherwise occupied with critical work issues.  I'm hoping to process
those this weekend.

I don't consider myself a gatekeeper and I won't complain if git-subtree
patches are accepted without my review, especially if I am caught up in
other things as I am now.  Anyone is welcome to prepare, review and
recommend patches for acceptance.  Junio is the real boss anyway.  :)

The whole point of Free Software is that anyone can contribute.  It
won't work any other way.

But when patches clearly take us backward, yeah, I'm going to have an
issue with that.  :)

                                  -David

Re: Subtree in Git

[Daniel Koester]

Hey Dave,

i am afraid my english is not sufficient enough to fully grasp your
statement:

> I also want to get at least one release under our belt.

Could you please elaborate on this?

I too would very much like to use git subtree, especially with the
changes from gith.com/helmo/git and recommend it to
friends/colleagues once/if it is merged into mainline.

Thank you,
dk

Re: Subtree in Git

[greened]

Daniel Koester <dk@hyve.org> writes:

> i am afraid my english is not sufficient enough to fully grasp your
> statement:
>
>> I also want to get at least one release under our belt.
>
> Could you please elaborate on this?

Sorry about my use of English idioms.  :)

I want to make sure that we get an official git release with subtree in
contrib/ before we move it to the top level.  That way, we've gone
though a whole test/release cycle and are fairly confident it all works
correctly.

> I too would very much like to use git subtree, especially with the
> changes from gith.com/helmo/git and recommend it to
> friends/colleagues once/if it is merged into mainline.

Oh, me too.  We have the same goals!

                          -Dave