[PATCH 2/3] subtree: fix "git subtree split --rejoin"
"git merge" in v2.9 prevents merging unrelated histories. "git subtree split --rejoin" creates unrelated histories when creating a split repo from a raw sub-directory that did not originate from an invocation of "git subtree add". Restore the original behavior by passing --allow-unrelated-histories when merging subtrees. This ensures that the synthetic history created by "git subtree split" can be merged. Add a test to ensure that this feature works as advertised. Reported-by: Brett Cundal <brett.cun...@iugome.com> Helped-by: Johannes Schindelin <johannes.schinde...@gmx.de> Signed-off-by: David Aguilar <dav...@gmail.com> --- This is a "re-implementation" of Brett's original RFC patch. I preferred adding a new line (rather than modifying the existing line) so I have no problem signing off on this being a distinct patch authored by me. contrib/subtree/git-subtree.sh | 1 + contrib/subtree/t/t7900-subtree.sh | 16 ++++++++ 2 files changed, 17 insertions(+) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index 7a39b30..b567eae 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -662,6 +662,7 @@ cmd_split() debug "Merging split branch into HEAD..." latest_old=$(cache_get latest_old) git merge -s ours \ + --allow-unrelated-histories \ -m "$(rejoin_msg "$dir" $latest_old $latest_new)" \ $latest_new >&2 || exit $? fi diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh index 431a2fe..e179b29 100755 --- a/contrib/subtree/t/t7900-subtree.sh +++ b/contrib/subtree/t/t7900-subtree.sh @@ -347,6 +347,22 @@ test_expect_success 'split sub dir/ with --rejoin' ' ' next_test +test_expect_success 'split sub dir/ with --rejoin from scratch' ' + subtree_test_create_repo "$subtree_test_count" && + test_create_commit "$subtree_test_count" main1 && + ( + cd "$subtree_test_count" && + mkdir "sub dir" && + echo file >"sub dir"/file && + git add "sub dir/file" && + git commit -m"sub dir file" && + split_hash=$(git subtree split --prefix="sub dir" --rejoin) && + git subtree split --prefix="sub dir" --rejoin && + check_equal "$(last_commit_message)" "Split '\''sub dir/'\'' into commit '\''$split_hash'\''" + ) + ' + +next_test test_expect_success 'split sub dir/ with --rejoin and --message' ' subtree_test_create_repo "$subtree_test_count" && subtree_test_create_repo "$subtree_test_count/sub proj" && -- 2.9.2.466.g8c6d1f9.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] subtree: add 'git-subtree-repo' and list command
Nicola Paolucci <npaolu...@atlassian.com> writes: > To my knowledge 'git subtree' currently lacks a way to > track where injected repositories come from originally. > Adding this information allows for useful extensions to > the command and makes it easier to use subtrees to track > external dependencies. Thanks for working on this. I just sent a reply to your earlier iteration. What is the intent for use of this? Is it simply to record from where commits were pulled or do you intend to use this information later on to have git-subtree guess from where to fetch future commits? I would be opposed to the latter because I think it potentially limits the utility of git-subtree and may be misleading. I frequently pull commits for a subtree from several different clones of the same reposiory. How does git-subtree list handle that situation? Does git-subtree list really print out repository information for every commit added by git-subtree? That's potentially a lot of commits. It might be more useful to aggregate repository information and only dump out unique URLs. In any case, processing all commits seems like a ton of work for such a simple operation. Maybe this information should be cached in .gitconfig. I'm actually in the middle of cleaing up metadata but I'm not going to block these commits due to that. Just be aware that it may change a bit. -David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] subtree: add 'git-subtree-repo' and list command
To my knowledge 'git subtree' currently lacks a way to track where injected repositories come from originally. Adding this information allows for useful extensions to the command and makes it easier to use subtrees to track external dependencies. In this patch series I propose to add a 'git-subtree-repo' line to the meta-data stored when injecting a tree in a repository with 'git subtree add'. The result looks like this: git-subtree-dir: .vim/bundle/fireplace git-subtree-split: b999b09cd9d69f359fa5668e81b09dcfde455cca git-subtree-repo: https://repo/user/vim-fireplace.git Thanks a lot to Mathias Nyman who has cleaned up my idea to add 'git-subtree-repo' and already submitted it for review. I added a test and a tiny fix to his patch and I resend it here (hence the v3 in the first patch). Using this extra value a simple 'git subtree list' command can be implemented which scans the checked out branch for subtrees injected: $ git subtree list .vim/bundle/fireplace https://github.com/tpope/vim-fireplace.git b999b0 I also added an optional '--resolve' flag to retrieve symbolic remote refs associated with the commit ids of the remote repository: $ git-subtree.sh list --resolve vim-airline https://repo/bling/vim-airline.git 4fa37e5e[...] vim-airline https://repo/bling/vim-airline.git HEAD vim-airline https://repo/bling/vim-airline.git refs/heads/master Nicola Paolucci (3): contrib/subtree: 'add' stores 'git-subtree-repo' contrib/subtree: new list command to list subtrees contrib/subtree: list --resolve gets symbolic refs contrib/subtree/git-subtree.sh | 140 + contrib/subtree/git-subtree.txt| 31 contrib/subtree/t/t7900-subtree.sh | 63 + 3 files changed, 205 insertions(+), 29 deletions(-) -- 2.7.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
On Sat, Mar 2, 2013 at 5:43 PM, Paul Campbell pcampb...@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 pcampb...@kemitix.net wrote: On Fri, Mar 1, 2013 at 2:28 AM, Kindjal kind...@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
Re: Subtree in Git
On Sat, Mar 2, 2013 at 9:05 AM, Paul Campbell pcampb...@kemitix.net wrote: On Fri, Mar 1, 2013 at 2:28 AM, Kindjal kind...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in 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 pcampb...@kemitix.net wrote: On Fri, Mar 1, 2013 at 2:28 AM, Kindjal kind...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
On Fri, Mar 1, 2013 at 2:28 AM, Kindjal kind...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-subtree: ignore git-subtree executable
Michael Schubert msc...@elegosoft.com writes: Signed-off-by: Michael Schubert msc...@elegosoft.com Obviously good. Applied and will send for integration. -David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-subtree: ignore git-subtree executable
Signed-off-by: Michael Schubert msc...@elegosoft.com --- contrib/subtree/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/subtree/.gitignore b/contrib/subtree/.gitignore index 7e77c9d..91360a3 100644 --- a/contrib/subtree/.gitignore +++ b/contrib/subtree/.gitignore @@ -1,4 +1,5 @@ *~ +git-subtree git-subtree.xml git-subtree.1 mainline -- 1.8.1.rc2.333.g912e06f.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
Herman van Rink r...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
On 10/22/2012 04:41 PM, d...@cray.com wrote: Herman van Rink r...@initfour.nl writes: On 10/21/2012 08:32 AM, Junio C Hamano wrote: Herman van Rink r...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
On Saturday, 27 October 2012 at 12:10 AM, Herman van Rink wrote: On 10/22/2012 04:41 PM, d...@cray.com (mailto:d...@cray.com) wrote: Herman van Rink r...@initfour.nl (mailto:r...@initfour.nl) writes: On 10/21/2012 08:32 AM, Junio C Hamano wrote: Herman van Rink r...@initfour.nl (mailto:r...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
Herman van Rink r...@initfour.nl writes: On 10/21/2012 08:32 AM, Junio C Hamano wrote: Herman van Rink r...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
Junio C Hamano gits...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
Herman van Rink r...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
Herman van Rink r...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
On 10/21/2012 08:32 AM, Junio C Hamano wrote: Herman van Rink r...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
Herman van Rink r...@initfour.nl writes: On 10/21/2012 08:32 AM, Junio C Hamano wrote: Herman van Rink r...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
On 10/21/2012 09:51 PM, Junio C Hamano wrote: Herman van Rink r...@initfour.nl writes: On 10/21/2012 08:32 AM, Junio C Hamano wrote: Herman van Rink r...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
On 07/11/2012 06:14 PM, d...@cray.com wrote: Herman van Rink r...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Met vriendelijke groet / Regards, Herman van Rink Initfour websolutions -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
Herman van Rink r...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
