Re: Why does 'submodule add' stage the relevant portions?
Am 26.03.2013 08:57, schrieb Ramkumar Ramachandra: > Jens Lehmann wrote: >> And leaving aside 'add', there are tons of submodules out there >> which were cloned with older Git who have their .git directory >> inside the work tree. So a new subcommand (or at least a helper >> script in contrib) to relocate the .git directory would really help >> here to migrate these legacy submodules without users having to >> worry about data loss. > > The question is: after using a "non-relocated submodule" for some > time, will the user suddenly decide to make it a "relocated submodule" > one day? I think quite some users - and definitely myself - will do that as soon as the full recursive checkout materialized, as that allows to remove submodules without any directory remaining and even to replace a submodule with a directory containing other files. And even with current Git you already get a clean work tree when using "git rm" or "git submodule deinit" (in current master) on a submodule iff it has its .git directory stored in the .git directory of the superproject. It is definitely not a Must Have right now, but I expect it to be that in the near future. >>> I meant a variant of add that would clone, but not stage. I was >>> arguing for a new subcommand so that I don't have to touch 'submodule >>> add', not for a rename. >> >> Ah, now I get it, I was confused by your reference to 'git submodule >> add '. I have to admit I still don't understand >> the use case you have for adding a submodule without staging it, but >> maybe it is just too late here. > > I usually reset after running 'git submodule add', because I rarely > commit the added submodule immediately after adding it. I'm not sure many submodule users do the same, but even then the normal ways of unstaging the submodule and .gitmodules should be sufficient here, no? I'd rather avoid adding a new command to git submodule for that. -- 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: Why does 'submodule add' stage the relevant portions?
Jens Lehmann wrote: > Am 25.03.2013 20:57, schrieb Ramkumar Ramachandra: >> Doesn't that sound horribly crippled to you? Is there any advantage >> to leaving the .git directory inside the submodule? Isn't it always >> better to relocate it? > > It's not crippled at all, that is just the way it was from submodule > day one. And no, it isn't always better to relocate it. E.g. when > you want to be able to just tar away work tree and history someplace > else because you don't have (or don't want) an upstream to push to, > you'd be very surprised a "submodule add" moved your .git directory > someplace else effectively nuking the backup of your history and > refs (guess under what circumstances you'll notice that). While I > believe most submodule users would benefit from such a relocation, I > consider the other use cases as valid and we would introduce silent > breakage on them. On the other hand I made all relevant commands > complain loudly about the .git directory in the submodule's work > tree when it matters, so users can do something about it when they > need it and are told so. I see. Thanks for the explanation. >> Why a new subcommand? Is there a problem if we do the relocation at >> the time of 'add'? Will some user expectation break? > > For me relocation at the time of 'add' would be ok with a new option > (and it might also make sense to have a config option changing the > default for users who want that), but not as the default. Makes sense. This seems trivial to implement: I'll get to work on it soon. > And leaving aside 'add', there are tons of submodules out there > which were cloned with older Git who have their .git directory > inside the work tree. So a new subcommand (or at least a helper > script in contrib) to relocate the .git directory would really help > here to migrate these legacy submodules without users having to > worry about data loss. The question is: after using a "non-relocated submodule" for some time, will the user suddenly decide to make it a "relocated submodule" one day? >> I meant a variant of add that would clone, but not stage. I was >> arguing for a new subcommand so that I don't have to touch 'submodule >> add', not for a rename. > > Ah, now I get it, I was confused by your reference to 'git submodule > add '. I have to admit I still don't understand > the use case you have for adding a submodule without staging it, but > maybe it is just too late here. I usually reset after running 'git submodule add', because I rarely commit the added submodule immediately after adding it. -- 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: Why does 'submodule add' stage the relevant portions?
On Mon, Mar 25, 2013 at 12:38 AM, Ramkumar Ramachandra wrote: > Git 2.0 is coming soon, so I'm excited about breaking a lot of > backward compatibility ;) It's a long way to 1.39 before we jump to 2.0 ;) -- Duy -- 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: Why does 'submodule add' stage the relevant portions?
Am 25.03.2013 20:57, schrieb Ramkumar Ramachandra: > Jens Lehmann wrote: >> Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra: >>> In my opinion, the 'git submodule add ' form is broken, because >>> it doesn't relocate the object store of the submodule repository (a >>> bug that we need to fix?). >> >> I don't think it is broken. Leaving the .git directory inside the >> submodule makes perfect sense for some users (e.g. those which never >> intend to push their submodule somewhere else) and doesn't do any >> harm unless you want to remove it again in the future (or need to go >> back to an older commit where the submodule directory would be in >> the way). We have to think very hard before making such changes to >> behavior quite some people may rely on, even though I agree some use >> cases would profit from it and I think we would do it differently if >> we could start over again. > > Doesn't that sound horribly crippled to you? Is there any advantage > to leaving the .git directory inside the submodule? Isn't it always > better to relocate it? It's not crippled at all, that is just the way it was from submodule day one. And no, it isn't always better to relocate it. E.g. when you want to be able to just tar away work tree and history someplace else because you don't have (or don't want) an upstream to push to, you'd be very surprised a "submodule add" moved your .git directory someplace else effectively nuking the backup of your history and refs (guess under what circumstances you'll notice that). While I believe most submodule users would benefit from such a relocation, I consider the other use cases as valid and we would introduce silent breakage on them. On the other hand I made all relevant commands complain loudly about the .git directory in the submodule's work tree when it matters, so users can do something about it when they need it and are told so. I'm not against changing that per se (we already did that for the "update" case when cloning submodules), but I'm really not convinced it is worth the downsides here (which it definitely was in the "update" case). >> What I think we need rather soonish is "git submodule to-gitfile", >> which would help your case too. We should then hint that in those >> cases where we refuse to remove a submodule when using "git rm" or >> "git submodule deinit" (or the "git mv" for submodules I'm currently >> preparing). > > Why a new subcommand? Is there a problem if we do the relocation at > the time of 'add'? Will some user expectation break? For me relocation at the time of 'add' would be ok with a new option (and it might also make sense to have a config option changing the default for users who want that), but not as the default. And leaving aside 'add', there are tons of submodules out there which were cloned with older Git who have their .git directory inside the work tree. So a new subcommand (or at least a helper script in contrib) to relocate the .git directory would really help here to migrate these legacy submodules without users having to worry about data loss. >>> I always use the 'git submodule add >>> ' form, which puts the object store of the >>> submodule repository in .git/modules of the parent repository. This >>> form is nothing like 'git add', but more like a 'git clone': arguably, >>> 'submodule clone' is a better name for it. >> >> Hmm, it does a clone first and then adds the submodule and the change >> to .gitmodules, so I still believe "add" is the correct term for it. >> So I really like the color the shed currently has ;-) > > I meant a variant of add that would clone, but not stage. I was > arguing for a new subcommand so that I don't have to touch 'submodule > add', not for a rename. Ah, now I get it, I was confused by your reference to 'git submodule add '. I have to admit I still don't understand the use case you have for adding a submodule without staging it, but maybe it is just too late here. >>> Maybe the WTF "You need to run this command from the toplevel of the >>> working tree" needs to be fixed first? I think it's a matter of a >>> simple pushd, popd before the operation and building the correct >>> relative path. >> >> I won't object such a change (even though I suspect it'll turn out >> more complicated than that). > > I'll have to investigate. Ok, looking forward to that as I believe this would be a worthwhile improvement. >>> I'm not sure how it'll work with nested submodules >>> though. Then again, I think nested submodules are Wrong; submodules >>> are probably not the right tool for the job. >> >> How did you come to that conclusion? Nested submodules make perfect >> sense and most people agree that in hindsight --recursive should have >> been the default, but again we can't simply change that now. > > Okay, I'll do it step-by-step now, with a live example: > 1. git clone gh:artagnon/dotfiles, a repository with submodules. > 2. git submodule update --init .elisp/auto-complete, a repository tha
Re: Why does 'submodule add' stage the relevant portions?
Jens Lehmann wrote: > Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra: >> In my opinion, the 'git submodule add ' form is broken, because >> it doesn't relocate the object store of the submodule repository (a >> bug that we need to fix?). > > I don't think it is broken. Leaving the .git directory inside the > submodule makes perfect sense for some users (e.g. those which never > intend to push their submodule somewhere else) and doesn't do any > harm unless you want to remove it again in the future (or need to go > back to an older commit where the submodule directory would be in > the way). We have to think very hard before making such changes to > behavior quite some people may rely on, even though I agree some use > cases would profit from it and I think we would do it differently if > we could start over again. Doesn't that sound horribly crippled to you? Is there any advantage to leaving the .git directory inside the submodule? Isn't it always better to relocate it? > What I think we need rather soonish is "git submodule to-gitfile", > which would help your case too. We should then hint that in those > cases where we refuse to remove a submodule when using "git rm" or > "git submodule deinit" (or the "git mv" for submodules I'm currently > preparing). Why a new subcommand? Is there a problem if we do the relocation at the time of 'add'? Will some user expectation break? >> I always use the 'git submodule add >> ' form, which puts the object store of the >> submodule repository in .git/modules of the parent repository. This >> form is nothing like 'git add', but more like a 'git clone': arguably, >> 'submodule clone' is a better name for it. > > Hmm, it does a clone first and then adds the submodule and the change > to .gitmodules, so I still believe "add" is the correct term for it. > So I really like the color the shed currently has ;-) I meant a variant of add that would clone, but not stage. I was arguing for a new subcommand so that I don't have to touch 'submodule add', not for a rename. >> Maybe the WTF "You need to run this command from the toplevel of the >> working tree" needs to be fixed first? I think it's a matter of a >> simple pushd, popd before the operation and building the correct >> relative path. > > I won't object such a change (even though I suspect it'll turn out > more complicated than that). I'll have to investigate. >> I'm not sure how it'll work with nested submodules >> though. Then again, I think nested submodules are Wrong; submodules >> are probably not the right tool for the job. > > How did you come to that conclusion? Nested submodules make perfect > sense and most people agree that in hindsight --recursive should have > been the default, but again we can't simply change that now. Okay, I'll do it step-by-step now, with a live example: 1. git clone gh:artagnon/dotfiles, a repository with submodules. 2. git submodule update --init .elisp/auto-complete, a repository that contains submodules. 3. .elisp/auto-complete/.gitmodules lists the submodules (lib/fuzzy, lib/ert, and lib/popup). Let's try to initialize them from that directory ... No! go back to toplevel. 4. Fine. Where are those submodules? git submodule status doesn't list them. 5. Okay, let's join the paths by hand and try anyway: git submodule update --init .elisp/auto-complete/lib/fuzzy. Did you forget to 'git add'? Fantastic. 6. How am I supposed to initialize the darn submodules?! 7. git submodule update --init --recursive .elisp/auto-complete is the ONLY way (is this even documented anywhere?). But I just wanted to initialize one, not all three! 8. Okay, now I want to execute a 'git submodule foreach' on just those three submodules. Seems impossible. Fine, I'll do it myself: for i in "lib/ert lib/fuzzy lib/popup"; do cd $i; git checkout master; git reset --hard origin/master; cd ../..; done 9. Whew. git status. Changes in auto-complete. git diff. "Submodule .elisp/auto-complete contains modified content". I'm not allowed to see what changed now? 10. git checkout master; git reset --hard origin/master in auto-complete. git status. How do I stage the changes in just auto-complete, and not in auto-complete's submodules? What is going on, seriously? This is just two levels of nesting: with more levels of nesting, things only get worse. Now, for the implementation. Do we have existing infrastructure to stage a hunk non-interactively? (The ability to select a hunk to stage/ unstage programmatically). If not, it might be quite a non-trivial thing to write. > [...] > Not that I know of. Damn. Then, it's certainly not worth the effort. Atleast not now, when there are bigger problems. -- 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: Why does 'submodule add' stage the relevant portions?
Ramkumar Ramachandra wrote: > This whole "backward compatibility" thing is not black-or-white: it's > shades of gray. Can I ask about how "backward incompatible" the other > suggestions I listed were, just so I get a rough idea of your scale? It depends on how important the change is and how painful the proposed transition is. Please don't gratuitously break things. If there is a smooth way to accomplish the intended effect without much downside, that is generally preferred, even if it is harder to write the code. There are no absolutes here. It is about helping people in the real world who never asked for such-and-such feature to avoid suffering real breakage. Hope that helps, Jonathan -- 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: Why does 'submodule add' stage the relevant portions?
Jonathan Nieder wrote: > Ramkumar Ramachandra wrote: > >> Okay, I'm confused: why are you waiting for 2.0 to change push.default >> then? Isn't that just a "slightly better default at the porcelain >> level" and hence a "regular enhancement"? > > No. Among other aspects, "git push" is used heavily by scripts. Oh, I see. I would've expected scripts to specify the refspec explicitly, instead of relying on a default like this. Then again, I saw jc/push-2.0-default-to-simple -- massive changes to scripts in our own testsuite. This whole "backward compatibility" thing is not black-or-white: it's shades of gray. Can I ask about how "backward incompatible" the other suggestions I listed were, just so I get a rough idea of your scale? Junio seems to be very extremist today. -- 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: Why does 'submodule add' stage the relevant portions?
Ramkumar Ramachandra wrote: > Okay, I'm confused: why are you waiting for 2.0 to change push.default > then? Isn't that just a "slightly better default at the porcelain > level" and hence a "regular enhancement"? No. Among other aspects, "git push" is used heavily by scripts. -- 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: Why does 'submodule add' stage the relevant portions?
Junio C Hamano wrote: > Ramkumar Ramachandra writes: > >> I'm talking about slightly better defaults at the porcelain level, >> at most. > > If a change does not even have to break backward compatibilty, that > is a regular enhancement and independent from 2.0, no? Okay, I'm confused: why are you waiting for 2.0 to change push.default then? Isn't that just a "slightly better default at the porcelain level" and hence a "regular enhancement"? You're not worried about breaking everyone's muscle memory (is that not part of backward compatibility)? So, if I understand correctly, I can do changes like the following at any time (provided the reviewers agree that they're sane): 1. Don't make 'git submodule add' stage (which is what this thread was originally about). 2. Set pull.autostash to true (I still have to re-roll and finish it ofcourse). 3. Set color.ui to auto. 4. Alias 'git status' to 'git status -sb'. 5. Set help.autocorrect to 20. -- 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: Why does 'submodule add' stage the relevant portions?
Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra: > Jens Lehmann wrote: >> Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra: >>> I find this behavior very inconsistent and annoying. Why would I want >>> to commit the submodule change immediately? Maybe I want to batch it >>> up with other changes and stage it at a later time. Why should I have >>> to unstage them manually now? I get the other side of the argument: >>> what if the user commits the .gitmodule change at a different time >>> from the file change? In other words, the user should have a way of >>> saying 'submodule stage' and 'submodule unstage'. >> >> Hmm, AFAIK you are the first to bring up such a feature, as in most >> use cases doing a "git (submodule) add " is expected to stage >> what you added. > > In my opinion, the 'git submodule add ' form is broken, because > it doesn't relocate the object store of the submodule repository (a > bug that we need to fix?). I don't think it is broken. Leaving the .git directory inside the submodule makes perfect sense for some users (e.g. those which never intend to push their submodule somewhere else) and doesn't do any harm unless you want to remove it again in the future (or need to go back to an older commit where the submodule directory would be in the way). We have to think very hard before making such changes to behavior quite some people may rely on, even though I agree some use cases would profit from it and I think we would do it differently if we could start over again. What I think we need rather soonish is "git submodule to-gitfile", which would help your case too. We should then hint that in those cases where we refuse to remove a submodule when using "git rm" or "git submodule deinit" (or the "git mv" for submodules I'm currently preparing). > I always use the 'git submodule add > ' form, which puts the object store of the > submodule repository in .git/modules of the parent repository. This > form is nothing like 'git add', but more like a 'git clone': arguably, > 'submodule clone' is a better name for it. Hmm, it does a clone first and then adds the submodule and the change to .gitmodules, so I still believe "add" is the correct term for it. So I really like the color the shed currently has ;-) > Maybe the WTF "You need to run this command from the toplevel of the > working tree" needs to be fixed first? I think it's a matter of a > simple pushd, popd before the operation and building the correct > relative path. I won't object such a change (even though I suspect it'll turn out more complicated than that). > I'm not sure how it'll work with nested submodules > though. Then again, I think nested submodules are Wrong; submodules > are probably not the right tool for the job. How did you come to that conclusion? Nested submodules make perfect sense and most people agree that in hindsight --recursive should have been the default, but again we can't simply change that now. >>> Now, for the implementation. Do we have existing infrastructure to >>> stage a hunk non-interactively? (The ability to select a hunk to >>> stage/ unstage programmatically). If not, it might be quite a >>> non-trivial thing to write. >> >> Have fun when adding two submodules and unstage only one of them >> later. I think this feature will not work unless you analyze >> .gitmodules and stage/unstage section-wise. > > Yes, which is why I asked if we have existing infrastructure to make > this possible. Not that I know of. -- 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: Why does 'submodule add' stage the relevant portions?
Ramkumar Ramachandra writes: > I'm talking about slightly better defaults at the porcelain level, > at most. If a change does not even have to break backward compatibilty, that is a regular enhancement and independent from 2.0, no? -- 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: Why does 'submodule add' stage the relevant portions?
Jonathan Nieder wrote: > Ramkumar Ramachandra wrote: >> Junio C Hamano wrote: >>> Ramkumar Ramachandra writes: > Git 2.0 is coming soon, so I'm excited about breaking a lot of backward compatibility ;) >>> >>> Don't. >> >> push.default is the necessary exception? > > A while ago there was a discussion of changes of the "If we were > starting over today, it would be obvious we should have made it work > the other way" kind and potential transition plans for them leading up > to 2.0. It's way too late to throw new breakage in. > > More generally, it doesn't make a lot of sense to save thinking about > such questions for the last minute before a new major release. If an > important change will require breaking compatibility and can only be > done using a painful 5-year transition, start today (and send patches > to the ML when an appropriate quiet moment comes to get review) so the > 5-year counter can start ticking. I agree that big important changes that break backward compatibility (like adding generation numbers to commit objects) will require this kind of time and effort to stabilize. Does a saner push.default value, or even tweaking the output of 'git status' to show what 'git status -sb' shows now (git status is porcelain, and no person in the right mind will write a script to parse it), require this? I'm talking about slightly better defaults at the porcelain level, at most. -- 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: Why does 'submodule add' stage the relevant portions?
Ramkumar Ramachandra wrote: > Junio C Hamano wrote: >> Ramkumar Ramachandra writes: >>> Git 2.0 is coming soon, so I'm excited about breaking a lot of >>> backward compatibility ;) >> >> Don't. > > push.default is the necessary exception? A while ago there was a discussion of changes of the "If we were starting over today, it would be obvious we should have made it work the other way" kind and potential transition plans for them leading up to 2.0. It's way too late to throw new breakage in. More generally, it doesn't make a lot of sense to save thinking about such questions for the last minute before a new major release. If an important change will require breaking compatibility and can only be done using a painful 5-year transition, start today (and send patches to the ML when an appropriate quiet moment comes to get review) so the 5-year counter can start ticking. Hoping that clarifies, Jonathan -- 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: Why does 'submodule add' stage the relevant portions?
Junio C Hamano wrote: > Ramkumar Ramachandra writes: > >> Git 2.0 is coming soon, so I'm excited about breaking a lot of >> backward compatibility ;) > > Don't. push.default is the necessary exception? -- 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: Why does 'submodule add' stage the relevant portions?
Ramkumar Ramachandra writes: > Git 2.0 is coming soon, so I'm excited about breaking a lot of > backward compatibility ;) Don't. I lack the sense of humor normal people seem to have, so even with the smiley, anybody making such a comment will be thrown into my "do not pay attention to them" box ;-). -- 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: Why does 'submodule add' stage the relevant portions?
Jens Lehmann wrote: > Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra: >> I find this behavior very inconsistent and annoying. Why would I want >> to commit the submodule change immediately? Maybe I want to batch it >> up with other changes and stage it at a later time. Why should I have >> to unstage them manually now? I get the other side of the argument: >> what if the user commits the .gitmodule change at a different time >> from the file change? In other words, the user should have a way of >> saying 'submodule stage' and 'submodule unstage'. > > Hmm, AFAIK you are the first to bring up such a feature, as in most > use cases doing a "git (submodule) add " is expected to stage > what you added. In my opinion, the 'git submodule add ' form is broken, because it doesn't relocate the object store of the submodule repository (a bug that we need to fix?). I always use the 'git submodule add ' form, which puts the object store of the submodule repository in .git/modules of the parent repository. This form is nothing like 'git add', but more like a 'git clone': arguably, 'submodule clone' is a better name for it. > Maybe you could teach the stage/unstage code to also > stage/unstage the corresponding part of the .gitmodules file, but > I'm not sure it is worth the hassle. Maybe not. I'm still not an heavy user of submodules; I notice many breakages and inconsistencies, but I'm not sure what to fix first, and how to go about fixing it. I'm yet to look at git-subtree and draw inspiration from its design. Maybe the WTF "You need to run this command from the toplevel of the working tree" needs to be fixed first? I think it's a matter of a simple pushd, popd before the operation and building the correct relative path. I'm not sure how it'll work with nested submodules though. Then again, I think nested submodules are Wrong; submodules are probably not the right tool for the job. >> Now, for the implementation. Do we have existing infrastructure to >> stage a hunk non-interactively? (The ability to select a hunk to >> stage/ unstage programmatically). If not, it might be quite a >> non-trivial thing to write. > > Have fun when adding two submodules and unstage only one of them > later. I think this feature will not work unless you analyze > .gitmodules and stage/unstage section-wise. Yes, which is why I asked if we have existing infrastructure to make this possible. -- 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: Why does 'submodule add' stage the relevant portions?
Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra: > I find this behavior very inconsistent and annoying. Why would I want > to commit the submodule change immediately? Maybe I want to batch it > up with other changes and stage it at a later time. Why should I have > to unstage them manually now? I get the other side of the argument: > what if the user commits the .gitmodule change at a different time > from the file change? In other words, the user should have a way of > saying 'submodule stage' and 'submodule unstage'. Hmm, AFAIK you are the first to bring up such a feature, as in most use cases doing a "git (submodule) add " is expected to stage what you added. Maybe you could teach the stage/unstage code to also stage/unstage the corresponding part of the .gitmodules file, but I'm not sure it is worth the hassle. > Now, for the implementation. Do we have existing infrastructure to > stage a hunk non-interactively? (The ability to select a hunk to > stage/ unstage programmatically). If not, it might be quite a > non-trivial thing to write. Have fun when adding two submodules and unstage only one of them later. I think this feature will not work unless you analyze .gitmodules and stage/unstage section-wise. -- 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
Why does 'submodule add' stage the relevant portions?
Hi, I find this behavior very inconsistent and annoying. Why would I want to commit the submodule change immediately? Maybe I want to batch it up with other changes and stage it at a later time. Why should I have to unstage them manually now? I get the other side of the argument: what if the user commits the .gitmodule change at a different time from the file change? In other words, the user should have a way of saying 'submodule stage' and 'submodule unstage'. Now, for the implementation. Do we have existing infrastructure to stage a hunk non-interactively? (The ability to select a hunk to stage/ unstage programmatically). If not, it might be quite a non-trivial thing to write. Git 2.0 is coming soon, so I'm excited about breaking a lot of backward compatibility ;) Thanks. Ram -- 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