* Subtree in Git @ 2012-04-27 18:48 Hilco Wijbenga 2012-04-27 20:38 ` dag 0 siblings, 1 reply; 35+ messages in thread From: Hilco Wijbenga @ 2012-04-27 18:48 UTC (permalink / raw) To: Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-04-27 18:48 Subtree in Git Hilco Wijbenga @ 2012-04-27 20:38 ` dag 2012-04-27 21:09 ` Hilco Wijbenga ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: dag @ 2012-04-27 20:38 UTC (permalink / raw) To: Hilco Wijbenga; +Cc: Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-04-27 20:38 ` dag @ 2012-04-27 21:09 ` Hilco Wijbenga 2012-05-01 8:34 ` Herman van Rink 2012-05-04 22:50 ` Daniel Koester 2 siblings, 0 replies; 35+ messages in thread From: Hilco Wijbenga @ 2012-04-27 21:09 UTC (permalink / raw) To: dag; +Cc: Git Users 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. :-) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 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 22:50 ` Daniel Koester 2 siblings, 1 reply; 35+ messages in thread From: Herman van Rink @ 2012-05-01 8:34 UTC (permalink / raw) To: dag; +Cc: Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 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 0 siblings, 2 replies; 35+ messages in thread From: greened @ 2012-05-04 2:26 UTC (permalink / raw) To: Herman van Rink; +Cc: dag, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-05-04 2:26 ` greened @ 2012-05-04 10:08 ` Herman van Rink 2012-05-05 4:25 ` Junio C Hamano 1 sibling, 0 replies; 35+ messages in thread From: Herman van Rink @ 2012-05-04 10:08 UTC (permalink / raw) To: greened; +Cc: dag, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 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 1 sibling, 2 replies; 35+ messages in thread From: Junio C Hamano @ 2012-05-05 4:25 UTC (permalink / raw) To: greened; +Cc: Herman van Rink, dag, Hilco Wijbenga, Git Users 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... ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-05-05 4:25 ` Junio C Hamano @ 2012-05-07 15:21 ` dag 2012-05-07 19:50 ` Herman van Rink 1 sibling, 0 replies; 35+ messages in thread From: dag @ 2012-05-07 15:21 UTC (permalink / raw) To: Junio C Hamano; +Cc: greened, Herman van Rink, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 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 1 sibling, 1 reply; 35+ messages in thread From: Herman van Rink @ 2012-05-07 19:50 UTC (permalink / raw) To: Junio C Hamano; +Cc: greened, dag, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 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 0 siblings, 2 replies; 35+ messages in thread From: dag @ 2012-05-07 21:57 UTC (permalink / raw) To: Herman van Rink; +Cc: Junio C Hamano, greened, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-05-07 21:57 ` dag @ 2012-05-11 20:24 ` Junio C Hamano 2012-05-23 15:13 ` dag 1 sibling, 0 replies; 35+ messages in thread From: Junio C Hamano @ 2012-05-11 20:24 UTC (permalink / raw) To: David A. Greene; +Cc: Herman van Rink, greened, Hilco Wijbenga, Git Users <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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 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 1 sibling, 1 reply; 35+ messages in thread From: dag @ 2012-05-23 15:13 UTC (permalink / raw) To: Herman van Rink; +Cc: Junio C Hamano, greened, Hilco Wijbenga, Git Users <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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-05-23 15:13 ` dag @ 2012-06-12 1:30 ` greened 2012-06-13 13:20 ` Herman van Rink 0 siblings, 1 reply; 35+ messages in thread From: greened @ 2012-06-12 1:30 UTC (permalink / raw) To: Herman van Rink, Junio C Hamano, Hilco Wijbenga, Git Users <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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-06-12 1:30 ` greened @ 2012-06-13 13:20 ` Herman van Rink 2012-07-11 16:14 ` dag 0 siblings, 1 reply; 35+ messages in thread From: Herman van Rink @ 2012-06-13 13:20 UTC (permalink / raw) To: greened; +Cc: Junio C Hamano, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-06-13 13:20 ` Herman van Rink @ 2012-07-11 16:14 ` dag 2012-10-20 20:03 ` Herman van Rink 0 siblings, 1 reply; 35+ messages in thread From: dag @ 2012-07-11 16:14 UTC (permalink / raw) To: Herman van Rink; +Cc: greened, Junio C Hamano, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-07-11 16:14 ` dag @ 2012-10-20 20:03 ` Herman van Rink 2012-10-21 6:32 ` Junio C Hamano 0 siblings, 1 reply; 35+ messages in thread From: Herman van Rink @ 2012-10-20 20:03 UTC (permalink / raw) To: Junio C Hamano; +Cc: dag, greened, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-10-20 20:03 ` Herman van Rink @ 2012-10-21 6:32 ` Junio C Hamano 2012-10-21 15:09 ` Herman van Rink 0 siblings, 1 reply; 35+ messages in thread From: Junio C Hamano @ 2012-10-21 6:32 UTC (permalink / raw) To: Herman van Rink; +Cc: dag, greened, Hilco Wijbenga, Git Users 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 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-22 14:41 ` dag 0 siblings, 2 replies; 35+ messages in thread From: Herman van Rink @ 2012-10-21 15:09 UTC (permalink / raw) To: Junio C Hamano; +Cc: dag, greened, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 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:44 ` dag 2012-10-22 14:41 ` dag 1 sibling, 2 replies; 35+ messages in thread From: Junio C Hamano @ 2012-10-21 19:51 UTC (permalink / raw) To: Herman van Rink; +Cc: dag, greened, Hilco Wijbenga, Git Users 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 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 1 sibling, 1 reply; 35+ messages in thread From: Herman van Rink @ 2012-10-21 20:23 UTC (permalink / raw) To: Junio C Hamano, dag; +Cc: greened, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-10-21 20:23 ` Herman van Rink @ 2012-10-22 14:47 ` dag 0 siblings, 0 replies; 35+ messages in thread From: dag @ 2012-10-22 14:47 UTC (permalink / raw) To: Herman van Rink; +Cc: Junio C Hamano, greened, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-10-21 19:51 ` Junio C Hamano 2012-10-21 20:23 ` Herman van Rink @ 2012-10-22 14:44 ` dag 1 sibling, 0 replies; 35+ messages in thread From: dag @ 2012-10-22 14:44 UTC (permalink / raw) To: Junio C Hamano; +Cc: Herman van Rink, greened, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-10-21 15:09 ` Herman van Rink 2012-10-21 19:51 ` Junio C Hamano @ 2012-10-22 14:41 ` dag 2012-10-26 13:10 ` Herman van Rink 1 sibling, 1 reply; 35+ messages in thread From: dag @ 2012-10-22 14:41 UTC (permalink / raw) To: Herman van Rink; +Cc: Junio C Hamano, greened, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-10-22 14:41 ` dag @ 2012-10-26 13:10 ` Herman van Rink 2012-10-26 13:58 ` David Michael Barr 2012-10-29 15:53 ` dag 0 siblings, 2 replies; 35+ messages in thread From: Herman van Rink @ 2012-10-26 13:10 UTC (permalink / raw) To: dag; +Cc: Junio C Hamano, greened, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-10-26 13:10 ` Herman van Rink @ 2012-10-26 13:58 ` David Michael Barr 2012-10-26 16:54 ` James Nylen ` (2 more replies) 2012-10-29 15:53 ` dag 1 sibling, 3 replies; 35+ messages in thread From: David Michael Barr @ 2012-10-26 13:58 UTC (permalink / raw) To: Herman van Rink; +Cc: dag, Junio C Hamano, greened, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 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 2 siblings, 0 replies; 35+ messages in thread From: James Nylen @ 2012-10-26 16:54 UTC (permalink / raw) To: David Michael Barr Cc: Herman van Rink, dag, Junio C Hamano, greened, Hilco Wijbenga, Git Users 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 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 2 siblings, 0 replies; 35+ messages in thread From: dag @ 2012-10-29 15:55 UTC (permalink / raw) To: David Michael Barr Cc: Herman van Rink, Junio C Hamano, greened, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 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 2 siblings, 1 reply; 35+ messages in thread From: Kindjal @ 2013-03-01 2:28 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2013-03-01 2:28 ` Kindjal @ 2013-03-01 22:05 ` Paul Campbell 2013-03-02 11:21 ` David Michael Barr 0 siblings, 1 reply; 35+ messages in thread From: Paul Campbell @ 2013-03-01 22:05 UTC (permalink / raw) To: Kindjal; +Cc: git, David Michael Barr 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2013-03-01 22:05 ` Paul Campbell @ 2013-03-02 11:21 ` David Michael Barr 2013-03-02 17:43 ` Paul Campbell 0 siblings, 1 reply; 35+ messages in thread From: David Michael Barr @ 2013-03-02 11:21 UTC (permalink / raw) To: Paul Campbell; +Cc: Kindjal, git 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2013-03-02 11:21 ` David Michael Barr @ 2013-03-02 17:43 ` Paul Campbell 2013-03-04 22:33 ` Paul Campbell 0 siblings, 1 reply; 35+ messages in thread From: Paul Campbell @ 2013-03-02 17:43 UTC (permalink / raw) To: David Michael Barr; +Cc: Kindjal, git 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2013-03-02 17:43 ` Paul Campbell @ 2013-03-04 22:33 ` Paul Campbell 0 siblings, 0 replies; 35+ messages in thread From: Paul Campbell @ 2013-03-04 22:33 UTC (permalink / raw) To: David Michael Barr; +Cc: Kindjal, git 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-10-26 13:10 ` Herman van Rink 2012-10-26 13:58 ` David Michael Barr @ 2012-10-29 15:53 ` dag 1 sibling, 0 replies; 35+ messages in thread From: dag @ 2012-10-29 15:53 UTC (permalink / raw) To: Herman van Rink; +Cc: Junio C Hamano, greened, Hilco Wijbenga, Git Users 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-04-27 20:38 ` dag 2012-04-27 21:09 ` Hilco Wijbenga 2012-05-01 8:34 ` Herman van Rink @ 2012-05-04 22:50 ` Daniel Koester 2012-06-12 1:32 ` greened 2 siblings, 1 reply; 35+ messages in thread From: Daniel Koester @ 2012-05-04 22:50 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Subtree in Git 2012-05-04 22:50 ` Daniel Koester @ 2012-06-12 1:32 ` greened 0 siblings, 0 replies; 35+ messages in thread From: greened @ 2012-06-12 1:32 UTC (permalink / raw) To: Daniel Koester; +Cc: git 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2013-03-04 22:33 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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 NNTP newsgroup(s).