{"thread":{"id":"44380","subject":"\"git subtree --squash\" interacts poorly with revert, merge, and rebase","startedAt":"2016-10-26T23:07:36Z","lastAt":"2016-11-14T22:37:50Z","messageCount":11,"participants":["Matt McCutchen","Stefan Beller","Junio C Hamano","Peter Williams"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"304927","messageId":"1477523244.2764.114.camel@mattmccutchen.net","threadId":"44380","inReplyTo":null,"subject":"\"git subtree --squash\" interacts poorly with revert, merge, and rebase","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2016-10-26T23:07:24Z","receivedAt":"2016-10-26T23:07:36Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"I'm the lead developer of a research software application (https://bitb\nucket.org/objsheets/objsheets) that uses modified versions of two\nthird-party libraries, which we need to version and distribute along\nwith our application.  For better or for worse, we haven't made it a\npriority to upstream our changes, so for now we just want to optimize\nfor ease of (1) making and reviewing changes and (2) upgrading to newer\nupstream versions.\n\nWe've been using git submodules, but that's a pain for several reasons:\n- We have to run \"git submodule update\" manually.\n- We have to make separate commits and manage corresponding topic\nbranches for the superproject and subprojects.\n- A diff of the superproject doesn't include the content of\nsubprojects.\n\nRecently I looked into switching to the \"git subtree\" contrib tool in\nthe --squash mode, but I identified a few drawbacks compared to\nsubmodules:\n\n1. The upstream commit on which the subtree is based is assumed to be\ngiven by the latest squash commit in \"git log\".  This means that (i) a\nchange to a different upstream commit can't be reverted with \"git\nrevert\" and (ii) a \"git merge\" of two superproject branches based on\ndifferent upstream commits may successfully merge the content of the\nupstream commits but leave the tool thinking the subtree is based on an\narbitrary one of the two commits.\n\n2. Rebasing messes up the merge commits generated by \"git subtree --\nsquash\".  --preserve-merges worked in a simple test but supposedly\ndoesn't work if there are conflicts or I want to reorder commits with\n--interactive.\n\nMaybe we would never hit any of these problems in practice, but they\ngive me a bad enough feeling that I'm planning to write my own tool\nthat tracks the upstream commit ID in a file (like a submodule) and\ndoesn't generate any extra commits.  Without generating extra commits,\nthe only place to store the upstream content in the superproject would\nbe in another subtree, which would take up disk space in every working\ntree unless developers manually set skip-worktree.  I think I prefer to\nnot store the upstream content and just have the tool fetch it from a\nlocal subproject repository each time it's needed.\n\nI'll of course post the tool on the web and would be happy to see it\nintegrated into \"git subtree\" if that makes sense, but I don't know how\nmuch time I'd be willing to put into making that happen.\n\nAny advice?\n\nThanks,\nMatt\n"},{"id":"304930","messageId":"CAGZ79kaw0s_PC2AstRVwFT8N1CJVC_7yQfC19zPzRjAqkSpMDg@mail.gmail.com","threadId":"44380","inReplyTo":"1477523244.2764.114.camel@mattmccutchen.net","subject":"Re: \"git subtree --squash\" interacts poorly with revert, merge, and rebase","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-26T23:23:44Z","receivedAt":"2016-10-26T23:23:52Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Oct 26, 2016 at 4:07 PM, Matt McCutchen wrote:\n> I'm the lead developer of a research software application (https://bitb\n> ucket.org/objsheets/objsheets) that uses modified versions of two\n> third-party libraries, which we need to version and distribute along\n> with our application. For better or for worse, we haven't made it a\n> priority to upstream our changes, so for now we just want to optimize\n> for ease of (1) making and reviewing changes and (2) upgrading to newer\n> upstream versions.\n>\n> We've been using git submodules, but that's a pain for several reasons:\n> - We have to run \"git submodule update\" manually.\n\nThat is true for now. :( But there are plans to revive a patch series\nto include updating the submodule into git-checkout.\n\nhttps://github.com/stefanbeller/git/commits/submodule-co\n\n> - We have to make separate commits and manage corresponding topic\n> branches for the superproject and subprojects.\n\nWell yeah, that is how submodule work on a conceptual level.\nWhile having multiple commits may seem like overhead, note\nthe subtle difference for these commits. One if deep down in the\nstack patching one of the submodules, the other is a high level\ncommit advancing the submodule pointer.\n\nNote that the target audience of these two commit messages\nmight be vastly different, hence can be worded differently.\n(The submodule describing how you fixed e.g. a memleak or race condition\nand the superproject describes on why you needed to include that submodule,\ne.g. because you switched your toplevel application to use threads.)\n\n> - A diff of the superproject doesn't include the content of\n> subprojects.\n\nA recent patch series by Jacob Keller (jk/diff-submodule-diff-inline)\ntaught git diff to show the diff in the submodule as well, see\ncommits that are merged in 305d7f133956a5f43c94d938beabbfbb0ac1753c\nor:\nhttps://kernel.googlesource.com/pub/scm/git/git/+/fd47ae6a5b9cc0cfc56c1f7c43db612d26ca4b75%5E%21/#F1\n\nAlthough this is just Git, you probably also have a code review system that\nwould need that change as well. Also it is not part of any release yet, but\nsoon will be.\n\nIs there anything else besides these 3 points that encourages you to\nswitch away from submodules?\n\nThanks,\nStefan\n"},{"id":"304931","messageId":"xmqqk2cuach3.fsf@gitster.mtv.corp.google.com","threadId":"44380","inReplyTo":"CAGZ79kaw0s_PC2AstRVwFT8N1CJVC_7yQfC19zPzRjAqkSpMDg@mail.gmail.com","subject":"Re: \"git subtree --squash\" interacts poorly with revert, merge, and rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-26T23:59:20Z","receivedAt":"2016-10-26T23:59:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n>> - We have to make separate commits and manage corresponding topic\n>> branches for the superproject and subprojects.\n>\n> Well yeah, that is how submodule work on a conceptual level.\n> While having multiple commits may seem like overhead, note\n> the subtle difference for these commits. One if deep down in the\n> stack patching one of the submodules, the other is a high level\n> commit advancing the submodule pointer.\n>\n> Note that the target audience of these two commit messages\n> might be vastly different, hence can be worded differently.\n> (The submodule describing how you fixed e.g. a memleak or race condition\n> and the superproject describes on why you needed to include that submodule,\n> e.g. because you switched your toplevel application to use threads.)\n\nBoth good points. \n\nAnother thing to keep in mind is that in a well-organized project,\nit is expected that you would have multiple commits in a submodule,\nsolving one single issue that is needed by the superproject in a\nfiner grained way, before the resulting submodule tip is recorded in\nthe tree of the superproject in one commit. IOW, between the time\nthe superproject's history moves by one commit, the submodule may\nhave multiple commits in order for the submodule to become ready to\nbe consumed by the superproject.\n\n\n"},{"id":"304938","messageId":"1477533150.2764.147.camel@mattmccutchen.net","threadId":"44380","inReplyTo":"CAGZ79kaw0s_PC2AstRVwFT8N1CJVC_7yQfC19zPzRjAqkSpMDg@mail.gmail.com","subject":"Re: \"git subtree --squash\" interacts poorly with revert, merge, and rebase","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2016-10-27T01:52:30Z","receivedAt":"2016-10-27T01:52:42Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"Hi Stefan,\n\nI appreciate the effort to remove obstacles to the use of submodules!\n It looks like a custom tool is probably still our best option at this\ntime, though we can always switch back to submodules later.\n\nOn Wed, 2016-10-26 at 16:23 -0700, Stefan Beller wrote:\n> On Wed, Oct 26, 2016 at 4:07 PM, Matt McCutchen wrote:\n> > - We have to make separate commits and manage corresponding topic\n> > branches for the superproject and subprojects.\n> \n> Well yeah, that is how submodule work on a conceptual level.\n> While having multiple commits may seem like overhead, note\n> the subtle difference for these commits. One if deep down in the\n> stack patching one of the submodules, the other is a high level\n> commit advancing the submodule pointer.\n> \n> Note that the target audience of these two commit messages\n> might be vastly different, hence can be worded differently.\n> (The submodule describing how you fixed e.g. a memleak or race condition\n> and the superproject describes on why you needed to include that submodule,\n> e.g. because you switched your toplevel application to use threads.)\n\nI understand one can adhere to that philosophy, but I don't see the\npractical benefit of doing so in our case compared to using a \"git\nsubtree\"-like approach and making a single commit.  It would just be us\nlooking at both commits.  If we do upstream any of the library changes,\nwe'll probably have to rework them anyway.\n\n> > - A diff of the superproject doesn't include the content of\n> > subprojects.\n\n> Although this is just Git, you probably also have a code review system that\n> would need that change as well.\n\nIndeed.  We currently use Bitbucket.  I'd be open to switching, though\nmaybe not just for this.\n\n> Is there anything else besides these 3 points that encourages you to\n> switch away from submodules?\n\nThose 3 are the ongoing pain points I can think of.  There are a few\nother drawbacks compared to \"git subtree\" that come up less often:\n\n1b. On another project, I was working with a teammate who was new to\nversion control and not very careful, who forgot to run \"git submodule\nupdate\" and ended up committing back the old submodule pointer.\n Thankfully, this hasn't happened yet on my current project.\n\n4. I pushed several dangling submodule pointers before I learned I\ncould set push.recurseSubmodules = check.  This isn't the default; each\ndeveloper has to do it manually.  (In theory, I could put such things\nin a setup script for them to run if they trust me.)\n\n5. Stashing changes to both the superproject and the subproject takes\nmore steps.\n\n6. I use multiple worktrees (with \"git worktree\") because of #5 and\nalso so that I can run two versions of the application at the same time\nand compare the behavior.  Using \"git worktree\" with submodules is\nofficially unsupported, though I was able to get things working by\nmanually editing some files.\n\n7. We have to set up a repository for each subproject on our hosting\nservice.  Anyone who forks our application and modifies a subproject\nhas to set up a subproject repository and carry a change to .gitmodules\nto point to their repository.  If we use relative URLs in .gitmodules,\nit's even worse: anyone who forks our application has to set up\nrepositories for all the subprojects, even if they don't modify them.\n\nMatt\n"},{"id":"304939","messageId":"CAGZ79kb1bb5e5hKpnkFqLOsPow5xt8zczWmZNxMMt5nA84tf-w@mail.gmail.com","threadId":"44380","inReplyTo":"1477533150.2764.147.camel@mattmccutchen.net","subject":"Re: \"git subtree --squash\" interacts poorly with revert, merge, and rebase","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-27T02:03:55Z","receivedAt":"2016-10-27T02:04:03Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Oct 26, 2016 at 6:52 PM, Matt McCutchen wrote:\n> Hi Stefan,\n>\n> I appreciate the effort to remove obstacles to the use of submodules!\n> It looks like a custom tool is probably still our best option at this\n> time, though we can always switch back to submodules later.\n>\n> On Wed, 2016-10-26 at 16:23 -0700, Stefan Beller wrote:\n>> On Wed, Oct 26, 2016 at 4:07 PM, Matt McCutchen wrote:\n>> > - We have to make separate commits and manage corresponding topic\n>> > branches for the superproject and subprojects.\n>>\n>> Well yeah, that is how submodule work on a conceptual level.\n>> While having multiple commits may seem like overhead, note\n>> the subtle difference for these commits. One if deep down in the\n>> stack patching one of the submodules, the other is a high level\n>> commit advancing the submodule pointer.\n>>\n>> Note that the target audience of these two commit messages\n>> might be vastly different, hence can be worded differently.\n>> (The submodule describing how you fixed e.g. a memleak or race condition\n>> and the superproject describes on why you needed to include that submodule,\n>> e.g. because you switched your toplevel application to use threads.)\n>\n> I understand one can adhere to that philosophy, but I don't see the\n> practical benefit of doing so in our case compared to using a \"git\n> subtree\"-like approach and making a single commit. It would just be us\n> looking at both commits. If we do upstream any of the library changes,\n> we'll probably have to rework them anyway.\n>\n>> > - A diff of the superproject doesn't include the content of\n>> > subprojects.\n>\n>> Although this is just Git, you probably also have a code review system that\n>> would need that change as well.\n>\n> Indeed. We currently use Bitbucket. I'd be open to switching, though\n> maybe not just for this.\n>\n>> Is there anything else besides these 3 points that encourages you to\n>> switch away from submodules?\n>\n> Those 3 are the ongoing pain points I can think of. There are a few\n> other drawbacks compared to \"git subtree\" that come up less often:\n>\n> 1b. On another project, I was working with a teammate who was new to\n> version control and not very careful, who forgot to run \"git submodule\n> update\" and ended up committing back the old submodule pointer.\n> Thankfully, this hasn't happened yet on my current project.\n>\n> 4. I pushed several dangling submodule pointers before I learned I\n> could set push.recurseSubmodules = check. This isn't the default; each\n> developer has to do it manually. (In theory, I could put such things\n> in a setup script for them to run if they trust me.)\n\nThere is a current series in flight/for review that makes \"check\" default.\n(It is blocked as check has some performance issues when having lots\nof commits to be pushed, so it may take a while and not show up in the\nnext release)\n\n>\n> 5. Stashing changes to both the superproject and the subproject takes\n> more steps.\n\nTrue, so you'd want to have a `git stash --recurse-submodules={yes,no}`\nwhere the command line option is configurable, so you don't have to type\nit all the time?\n\n>\n> 6. I use multiple worktrees (with \"git worktree\") because of #5 and\n> also so that I can run two versions of the application at the same time\n> and compare the behavior. Using \"git worktree\" with submodules is\n> officially unsupported, though I was able to get things working by\n> manually editing some files.\n\nHeh, true. I made an attempt on fixing git worktree a few weeks ago, but that\ndid not go anywhere, but it's still on the TODO list.\n\nYou can use git clone --reference with --recurse-submodule though when\nhaving bandwidth concerns. It doesn't deliver the full worktree experience\nthough as it would be separate clones with shared object store.\n\n>\n> 7. We have to set up a repository for each subproject on our hosting\n> service. Anyone who forks our application and modifies a subproject\n> has to set up a subproject repository and carry a change to .gitmodules\n> to point to their repository. If we use relative URLs in .gitmodules,\n> it's even worse: anyone who forks our application has to set up\n> repositories for all the subprojects, even if they don't modify them.\n>\n> Matt\n\nYeah the model of referencing in gitmodules is conceptually broken.\nI don't even claim it is on my todo list. ;)\n\nThanks for pointing out the issues though. they align to what\nwe plan on doing for submodules, so ... the plan actually makes\nsense :)\n\nThanks,\nStefan\n"},{"id":"304942","messageId":"1477536130.1570.10.camel@mattmccutchen.net","threadId":"44380","inReplyTo":"CAGZ79kb1bb5e5hKpnkFqLOsPow5xt8zczWmZNxMMt5nA84tf-w@mail.gmail.com","subject":"Re: \"git subtree --squash\" interacts poorly with revert, merge, and rebase","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2016-10-27T02:42:10Z","receivedAt":"2016-10-27T02:42:18Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"On Wed, 2016-10-26 at 19:03 -0700, Stefan Beller wrote:\n> On Wed, Oct 26, 2016 at 6:52 PM, Matt McCutchen wrote:\n> > 4. I pushed several dangling submodule pointers before I learned I\n> > could set push.recurseSubmodules = check.  This isn't the default; each\n> > developer has to do it manually.  (In theory, I could put such things\n> > in a setup script for them to run if they trust me.)\n> \n> There is a current series in flight/for review that makes \"check\" default.\n> (It is blocked as check has some performance issues when having lots\n> of commits to be pushed, so it may take a while and not show up in the\n> next release)\n\nGreat!  One other thing: IIRC, \"check\" does not distinguish between\ndifferent remotes.  For example, suppose I fork a project that already\nhas a submodule and I have a pair of repositories that pull from the\n\"upstream\" repositories and push to \"origin\" repositories for my\nproject.  Suppose I upgrade to a new upstream version and find that I'm\n(temporarily) able to use the upstream submodule without modifications.\n The \"check\" feature won't stop me from pushing a pointer into the\n\"origin\" superproject that points to a commit that exists in the\n\"upstream\" subproject but not the \"origin\" subproject.\n\n> > 5. Stashing changes to both the superproject and the subproject takes\n> > more steps.\n> \n> True, so you'd want to have a `git stash --recurse-submodules={yes,no}`\n> where the command line option is configurable, so you don't have to type\n> it all the time?\n\nSounds good.  I'm sure you realize this is not just a matter of running\n\"git stash\" in each submodule because there are many ways the stash\nstacks could get out of lockstep.  The submodule content needs to be\nincorporated into the superproject stash.\n\n> Thanks for pointing out the issues though. they align to what\n> we plan on doing for submodules, so ... the plan actually makes\n> sense :)\n\nAgain, I'm thrilled you're working on this, even if I don't use it on\nmy current project.\n\nMatt\n"},{"id":"304944","messageId":"f07745f8-d0ff-c41f-fd44-0812757fbd43@bigpond.net.au","threadId":"44380","inReplyTo":"xmqqk2cuach3.fsf@gitster.mtv.corp.google.com","subject":"Re: \"git subtree --squash\" interacts poorly with revert, merge, and rebase","fromName":"Peter Williams","fromEmail":"pwil3058@bigpond.net.au","sentAt":"2016-10-27T04:23:20Z","receivedAt":"2016-10-27T04:39:47Z","isPatch":false,"sender":{"key":"pwil3058@bigpond.net.au","avatar":"https://gravatar.com/avatar/fc711ad9d9890c01c6ede5a99a62a8b8ca82a3eef0def8ef98e0ec7da7f99367?d=mp&s=160"},"body":"On 27/10/16 09:59, Junio C Hamano wrote:\n> Stefan Beller writes:\n>\n>>> - We have to make separate commits and manage corresponding topic\n>>> branches for the superproject and subprojects.\n>>\n>> Well yeah, that is how submodule work on a conceptual level.\n>> While having multiple commits may seem like overhead, note\n>> the subtle difference for these commits. One if deep down in the\n>> stack patching one of the submodules, the other is a high level\n>> commit advancing the submodule pointer.\n>>\n>> Note that the target audience of these two commit messages\n>> might be vastly different, hence can be worded differently.\n>> (The submodule describing how you fixed e.g. a memleak or race condition\n>> and the superproject describes on why you needed to include that submodule,\n>> e.g. because you switched your toplevel application to use threads.)\n>\n> Both good points.\n>\n> Another thing to keep in mind is that in a well-organized project,\n> it is expected that you would have multiple commits in a submodule,\n> solving one single issue that is needed by the superproject in a\n> finer grained way, before the resulting submodule tip is recorded in\n> the tree of the superproject in one commit. IOW, between the time\n> the superproject's history moves by one commit, the submodule may\n> have multiple commits in order for the submodule to become ready to\n> be consumed by the superproject.\n>\n>\n\nI'm a relatively new user of submodules and I quite like them (having \ntried a few other strategies for sharing common code between multiple \nprojects and found them quite painful) and find them fairly easy to use. \n I especially like the fact that the submodule command isn't very \ncomplicated and that the best method for managing commits, etc in the \nsubmodule is to cd into their root directory and then treat them like \nany other git repository (greatly reducing the amount of new stuff that \nyou have to learn in order to use them). Also, from my experience so \nfar, I see three different types of work going on within my workspaces \nthat include submodules:\n\n1. I'm working on changes to the submodule and using the superproject \nthat it's checked out in to test those changes in which case most of the \nchange is occurring in the submodule with changes in the superproject \nusually being small one related to API changes in the submodule.\n\n2. I'm working on changes in the superproject and the only changes that \nget made in the submodules are to fix bugs uncovered by the work in the \nsuperproject.\n\n3. I'm modifying a superproject to accommodate changes to a submodule \nthat's changed as a result of having changes pulled from another repository.\n\nIn none of these cases do I feel the desire/need to commit the changes \nto the superproject and submodule(s) with a single commit command which \nmore or less agrees with your points.\n\nHowever, for git commands such as diff/status whose job is to display \ninformation it would be nice if they had a --recursive option to \noverride the default submodule diff/status and show details of the \nchanges in the submodules. Sometimes you want to see the big picture in \ndetail.\n\n"},{"id":"304946","messageId":"xmqqtwby8hu8.fsf@gitster.mtv.corp.google.com","threadId":"44380","inReplyTo":"f07745f8-d0ff-c41f-fd44-0812757fbd43@bigpond.net.au","subject":"Re: \"git subtree --squash\" interacts poorly with revert, merge, and rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-27T05:46:23Z","receivedAt":"2016-10-27T05:46:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Williams writes:\n\n> However, for git commands such as diff/status whose job is to display\n> information it would be nice if they had a --recursive option to\n> override the default submodule diff/status and show details of the\n> changes in the submodules. Sometimes you want to see the big picture\n> in detail.\n\nI won't disagree. My comment was only on this part from the original:\n\n>> - We have to make separate commits and manage corresponding topic\n>> branches for the superproject and subprojects.\n\nand on this point, we seem to be in agreement.\n\n"},{"id":"304948","messageId":"xmqqpomm8h6v.fsf@gitster.mtv.corp.google.com","threadId":"44380","inReplyTo":"xmqqtwby8hu8.fsf@gitster.mtv.corp.google.com","subject":"Re: \"git subtree --squash\" interacts poorly with revert, merge, and rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-27T06:00:24Z","receivedAt":"2016-10-27T06:00:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Peter Williams writes:\n>\n>> However, for git commands such as diff/status whose job is to display\n>> information it would be nice if they had a --recursive option to\n>> override the default submodule diff/status and show details of the\n>> changes in the submodules. Sometimes you want to see the big picture\n>> in detail.\n>\n> I won't disagree. My comment was only on this part from the original:\n>\n>>> - We have to make separate commits and manage corresponding topic\n>>> branches for the superproject and subprojects.\n>\n> and on this point, we seem to be in agreement.\n\nOh, and as Stefan mentioned, a \"git diff\" that recurses into the\nsubmodules to give you detailed big picture has been in 'next'\n(perhaps aready in 'master' as of tonight, but I am not sure\noffhand) to be tested, together with many other fixes and\nenhancements that all are waiting to be included in future releases.\n\nThe more people try and give feedback to these branches early, the\nmore solid release with better support for more goodies you'd want\nwe will be able to give you. Early adopters are always appreciated\nbut especially in time like this before the feature freeze for the\nupcoming release (see tinyurl.com/gitCal for the schedule), they are\nof great help.\n\nStart by cloning from any one of these places\n\n git://git.kernel.org/pub/scm/git/git.git/\n https://kernel.googlesource.com/pub/scm/git/git\n git://repo.or.cz/alt-git.git/\n https://github.com/git/git/\n\nand then\n\n $ git checkout -b next origin/next\n : read INSTALL to figure out if any custom options are needed\n : in the following 'make' invocations for your environment\n $ make && make install\n $ PATH=$HOME/bin:$PATH\n\nto join the fun.\n"},{"id":"305731","messageId":"1478814800.2878.10.camel@mattmccutchen.net","threadId":"44380","inReplyTo":"1477523244.2764.114.camel@mattmccutchen.net","subject":"Re: \"git subtree --squash\" interacts poorly with revert, merge, and rebase","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2016-11-10T21:53:20Z","receivedAt":"2016-11-10T21:53:29Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"On Wed, 2016-10-26 at 19:07 -0400, Matt McCutchen wrote:\n> Maybe we would never hit any of these problems in practice, but they\n> give me a bad enough feeling that I'm planning to write my own tool\n> that tracks the upstream commit ID in a file (like a submodule) and\n> doesn't generate any extra commits.  Without generating extra commits,\n> the only place to store the upstream content in the superproject would\n> be in another subtree, which would take up disk space in every working\n> tree unless developers manually set skip-worktree.  I think I prefer to\n> not store the upstream content and just have the tool fetch it from a\n> local subproject repository each time it's needed.\n> \n> I'll of course post the tool on the web and would be happy to see it\n> integrated into \"git subtree\" if that makes sense, but I don't know how\n> much time I'd be willing to put into making that happen.\n\nI have named my tool \"git subtree-lite\" and posted it here:\n\nhttps://mattmccutchen.net/utils/git-subtree-lite.git/\n\nFor now, please email any bug reports, enhancement requests, or\nproposed patches to me.  I have philosophical concerns about hosting my\nown projects on services I don't control and practical concerns about a\n few \"forge\" apps that I looked into installing on my own web site, but\nif people are seriously interested in collaborating on this, I'll work\nsomething out.\n\nMatt\n"},{"id":"305924","messageId":"1479163040.2406.49.camel@mattmccutchen.net","threadId":"44380","inReplyTo":"1478814800.2878.10.camel@mattmccutchen.net","subject":"Re: \"git subtree --squash\" interacts poorly with revert, merge, and rebase","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2016-11-14T22:37:20Z","receivedAt":"2016-11-14T22:37:50Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"On Thu, 2016-11-10 at 16:53 -0500, Matt McCutchen wrote:\n> On Wed, 2016-10-26 at 19:07 -0400, Matt McCutchen wrote:\n> > \n> > Maybe we would never hit any of these problems in practice, but they\n> > give me a bad enough feeling that I'm planning to write my own tool\n> > that tracks the upstream commit ID in a file (like a submodule) and\n> > doesn't generate any extra commits.  Without generating extra commits,\n> > the only place to store the upstream content in the superproject would\n> > be in another subtree, which would take up disk space in every working\n> > tree unless developers manually set skip-worktree.  I think I prefer to\n> > not store the upstream content and just have the tool fetch it from a\n> > local subproject repository each time it's needed.\n> > \n> > I'll of course post the tool on the web and would be happy to see it\n> > integrated into \"git subtree\" if that makes sense, but I don't know how\n> > much time I'd be willing to put into making that happen.\n> \n> I have named my tool \"git subtree-lite\" and posted it here:\n> \n> https://mattmccutchen.net/utils/git-subtree-lite.git/\n\nAs I was doing additional research in preparation for adding git-\nsubtree-lite to the tools page\n(https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools),\nby chance I found an existing tool, Braid\n(http://cristibalan.github.io/braid/), whose design meets my\nrequirements.  I have a few minor concerns, but assuming I'm able to\nfix them without too much work and upstream accepts my patches, I plan\nto switch to Braid.\n\nI've made a properly marked section on the tools page for subproject\nmanagement tools:\n\nhttps://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Subprojects_or_sets_of_repositories\n\nin the hope that the next person with the same requirements as me finds\nBraid.  (I unfortunately didn't check that page before starting, but I\nwill the next time I need something.)\n\nMatt\n"}]}