{"thread":{"id":"13574","subject":"submodules workflow aches","startedAt":"2008-05-19T14:56:49Z","lastAt":"2008-05-19T18:55:00Z","messageCount":3,"participants":["Nigel Magnay","Chris Shoemaker"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"77275","messageId":"320075ff0805190756x3adf1684i3980aac15e2ddb88@mail.gmail.com","threadId":"13574","inReplyTo":null,"subject":"submodules workflow aches","fromName":"Nigel Magnay","fromEmail":"nigel.magnay@gmail.com","sentAt":"2008-05-19T14:56:49Z","receivedAt":"2008-05-19T14:56:49Z","isPatch":false,"sender":{"key":"nigel.magnay@gmail.com","avatar":"https://gravatar.com/avatar/d85cf38287bef3a8e4fa02358d2756d7589f8676c5eeb881ce2f6d731e4526c3?d=mp&s=160"},"body":"We've been using submodule support for a few months (and I've been\nchecking out the list to see what other people are doing); it works\nwell, but there's a couple of ache points (in the sense that if I'm to\nconvince SVN users to migrate, they're liable to point and laugh).\n\nThe first nuisance is the 'get me up to date' stanza of 'git pull &&\ngit submodule update' always leaving you on (no branch), even if you\nwere on [master] before, and the head commit now is also equal to\n[master]. Having to remember to go into several submodules and do 'git\ncheckout master' to get you back to ready-to-do-work mode isn't nice\n(and is worse if you're on autopilot, and someone has committed a\nsubmodule on a different branch\n\nThe second nuisance is around conflicts in submodules. If I make a\n(non-conflicting) change to a submodule, merge with the head and\ncommit, then when I do a 'git pull' in the superproject readiness to\ndo a push, I get a conflict. This is presumably because it doesn't\nknow that the submodule change is a fast-forward. It'd be nice if it\ncould figure that out, and not conflict?\n\nAre people writing their own wrapper scripts for this? I find I have a\nhard time explaining why it's all necessary to svn users who just (by\nand large) do 'svn up' and 'svn ci' on projects..\n"},{"id":"77280","messageId":"20080519181134.GA7928@pe.Belkin","threadId":"13574","inReplyTo":"320075ff0805190756x3adf1684i3980aac15e2ddb88@mail.gmail.com","subject":"Re: submodules workflow aches","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2008-05-19T18:11:34Z","receivedAt":"2008-05-19T18:11:34Z","isPatch":false,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Mon, May 19, 2008 at 03:56:49PM +0100, Nigel Magnay wrote:\n> We've been using submodule support for a few months (and I've been\n> checking out the list to see what other people are doing); it works\n> well, but there's a couple of ache points (in the sense that if I'm to\n> convince SVN users to migrate, they're liable to point and laugh).\n> \n> The first nuisance is the 'get me up to date' stanza of 'git pull &&\n> git submodule update' always leaving you on (no branch), even if you\n> were on [master] before, and the head commit now is also equal to\n> [master]. Having to remember to go into several submodules and do 'git\n> checkout master' to get you back to ready-to-do-work mode isn't nice\n> (and is worse if you're on autopilot, and someone has committed a\n> submodule on a different branch\n\nIt might help if you describe more completely how you expect it to behave\nunder a wide variety of conditions.  I suspect that the current behavior\nis the simplest behavior that remains correct under all conditions.\n\n> The second nuisance is around conflicts in submodules. If I make a\n> (non-conflicting) change to a submodule, merge with the head and\n> commit, then when I do a 'git pull' in the superproject readiness to\n> do a push, I get a conflict. This is presumably because it doesn't\n> know that the submodule change is a fast-forward. It'd be nice if it\n> could figure that out, and not conflict?\n\nIf I follow the scenario correctly, you're essentially pulling into a\ndirty working tree.  I guess you're saying that if the submodule\nwasn't touched by the merge, you'd like it to leave your working tree\ndirty?\n\n> Are people writing their own wrapper scripts for this? I find I have a\n> hard time explaining why it's all necessary to svn users who just (by\n> and large) do 'svn up' and 'svn ci' on projects..\n\nI'll throw out one nuisance that I hit, perhaps related to your second\none: in the super-module, rebasing a series containing a submodule\nupdate.  I start the rebase with a clean working tree, but since the\nrebase doesn't update the submodule, (which I wouldn't really want it\nto do anyway) the rebase aborts in the middle with:\n\n$ git rebase --continue \nplugin/submodule: needs update\nWorking tree is dirty\n\nforcing me to \"git submodule update\" in order to continue.\n\nThen, when the rebase finishes, my working tree is dirty again because\nthe submodule is out-of-date, so I have to \"submodule update\" AGAIN.\n\nAm I just missing the much better way to do this?\n\n-chris\n"},{"id":"77282","messageId":"320075ff0805191155rd55e36h61924d25c03a65cc@mail.gmail.com","threadId":"13574","inReplyTo":"20080519181134.GA7928@pe.Belkin","subject":"Re: submodules workflow aches","fromName":"Nigel Magnay","fromEmail":"nigel.magnay@gmail.com","sentAt":"2008-05-19T18:55:00Z","receivedAt":"2008-05-19T18:55:00Z","isPatch":false,"sender":{"key":"nigel.magnay@gmail.com","avatar":"https://gravatar.com/avatar/d85cf38287bef3a8e4fa02358d2756d7589f8676c5eeb881ce2f6d731e4526c3?d=mp&s=160"},"body":">> We've been using submodule support for a few months (and I've been\n>> checking out the list to see what other people are doing); it works\n>> well, but there's a couple of ache points (in the sense that if I'm to\n>> convince SVN users to migrate, they're liable to point and laugh).\n>>\n>> The first nuisance is the 'get me up to date' stanza of 'git pull &&\n>> git submodule update' always leaving you on (no branch), even if you\n>> were on [master] before, and the head commit now is also equal to\n>> [master]. Having to remember to go into several submodules and do 'git\n>> checkout master' to get you back to ready-to-do-work mode isn't nice\n>> (and is worse if you're on autopilot, and someone has committed a\n>> submodule on a different branch\n>\n> It might help if you describe more completely how you expect it to behave\n> under a wide variety of conditions.  I suspect that the current behavior\n> is the simplest behavior that remains correct under all conditions.\n>\n\nOh, I agree. git is actually much more powerful, but it (currently)\nrequires a lot more faffing for common usecases (unless of course I've\nmissed some new features, which is entirely possible).\n\nComing from the svn world, with a project containing many\nsvn:externals, a 'bring everything up to date, ready to continue work'\nis just a case of 'svn up'. In the git equivalent, it seems to be\ngit pull && git submodule update\n(for-each-submodule-that-changed) cd submodule && git checkout master\n\nIf module A was on branch [x] before submodule update, and after\nupdate sha1(HEAD)==sha1([x]), couldn't it return the module to being\non branch [x] ?\n\n>> The second nuisance is around conflicts in submodules. If I make a\n>> (non-conflicting) change to a submodule, merge with the head and\n>> commit, then when I do a 'git pull' in the superproject readiness to\n>> do a push, I get a conflict. This is presumably because it doesn't\n>> know that the submodule change is a fast-forward. It'd be nice if it\n>> could figure that out, and not conflict?\n>\n> If I follow the scenario correctly, you're essentially pulling into a\n> dirty working tree.  I guess you're saying that if the submodule\n> wasn't touched by the merge, you'd like it to leave your working tree\n> dirty?\n>\nI find this kinda stuff hard to describe :-)\n\nSuperproject SP, Modules M1 and M2\n\norigin:\nSP = sha1-x\n m1 = sha1-y\n m2 = sha1-z\n\nUser1 and User2 both have SP checked out@sha1-x.\n\nUser1 makes a change in M1, commits and updates origin (push) M1 and then SP.\n\norigin:\nSP = sha1-xx\n m1 = sha1-yy\n m2 = sha1=z\n\nUser2 makes a change in M1 that doesn't conflict with U1. commits and\nupdates origin M1 (needs to pull then push to automatically merge),\nproducing sha1-yyy.\nWhen trying to commit SP, push fails. pull then produces a conflict -\nSP[sha1-xx] says m1=sha1-yy, and local WC m1=sha1-yyy.\nBut - sha1-yyy is a fast-forward from sha1-yy, so it should be\nautomatically mergeable. Maybe. Either way it's a pain - most people\nseem to just ignore it and 'git add' each submodule and force the\ncommit anyway. But it basically happens virtually every commit (unless\nyou were the last person to do the SP commit and so it's not a merge),\nwhich is annoying especially since I'm asking svn users to replace a\n'svn up && svn ci' with an equivalent in the module /and/ the\nsuperproject /and/ to merge a (to the user irrelevant) conflict.\n\n\n>> Are people writing their own wrapper scripts for this? I find I have a\n>> hard time explaining why it's all necessary to svn users who just (by\n>> and large) do 'svn up' and 'svn ci' on projects..\n>\n> I'll throw out one nuisance that I hit, perhaps related to your second\n> one: in the super-module, rebasing a series containing a submodule\n> update.  I start the rebase with a clean working tree, but since the\n> rebase doesn't update the submodule, (which I wouldn't really want it\n> to do anyway) the rebase aborts in the middle with:\n>\n> $ git rebase --continue\n> plugin/submodule: needs update\n> Working tree is dirty\n>\n> forcing me to \"git submodule update\" in order to continue.\n>\n> Then, when the rebase finishes, my working tree is dirty again because\n> the submodule is out-of-date, so I have to \"submodule update\" AGAIN.\n>\n> Am I just missing the much better way to do this?\n>\n> -chris\n>\n"}]}