* Why does 'submodule add' stage the relevant portions?
@ 2013-03-24 17:38 Ramkumar Ramachandra
2013-03-25 8:35 ` Jens Lehmann
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Ramkumar Ramachandra @ 2013-03-24 17:38 UTC (permalink / raw)
To: Git List; +Cc: Jens Lehmann
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: Why does 'submodule add' stage the relevant portions? 2013-03-24 17:38 Why does 'submodule add' stage the relevant portions? Ramkumar Ramachandra @ 2013-03-25 8:35 ` Jens Lehmann 2013-03-25 8:59 ` Ramkumar Ramachandra 2013-03-25 17:51 ` Junio C Hamano 2013-03-26 3:27 ` Duy Nguyen 2 siblings, 1 reply; 18+ messages in thread From: Jens Lehmann @ 2013-03-25 8:35 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Git List 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 <path>" 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 8:35 ` Jens Lehmann @ 2013-03-25 8:59 ` Ramkumar Ramachandra 2013-03-25 18:43 ` Jens Lehmann 0 siblings, 1 reply; 18+ messages in thread From: Ramkumar Ramachandra @ 2013-03-25 8:59 UTC (permalink / raw) To: Jens Lehmann; +Cc: Git List 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 <path>" is expected to stage > what you added. In my opinion, the 'git submodule add <path>' 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 <repository> <path>' 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 8:59 ` Ramkumar Ramachandra @ 2013-03-25 18:43 ` Jens Lehmann 2013-03-25 19:57 ` Ramkumar Ramachandra 0 siblings, 1 reply; 18+ messages in thread From: Jens Lehmann @ 2013-03-25 18:43 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Git List 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 <path>" is expected to stage >> what you added. > > In my opinion, the 'git submodule add <path>' 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 > <repository> <path>' 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 18:43 ` Jens Lehmann @ 2013-03-25 19:57 ` Ramkumar Ramachandra 2013-03-25 22:57 ` Jens Lehmann 0 siblings, 1 reply; 18+ messages in thread From: Ramkumar Ramachandra @ 2013-03-25 19:57 UTC (permalink / raw) To: Jens Lehmann; +Cc: Git List Jens Lehmann wrote: > Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra: >> In my opinion, the 'git submodule add <path>' 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 >> <repository> <path>' 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 19:57 ` Ramkumar Ramachandra @ 2013-03-25 22:57 ` Jens Lehmann 2013-03-26 7:57 ` Ramkumar Ramachandra 0 siblings, 1 reply; 18+ messages in thread From: Jens Lehmann @ 2013-03-25 22:57 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Git List 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 <path>' 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 >>> <repository> <path>' 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 <repository> <path>'. 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 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. That has got nothing to do with nested submodules but is the toplevel requirement you already mentioned. > 4. Fine. Where are those submodules? git submodule status doesn't list them. Did you try 'git submodule status --recursive'? Without that option nested submodules won't work well at all (maybe we need a config option to let the user enable --recursive by default?). > 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. You either use --recursive to include all submodules or have to cd into the submodules superproject (.elisp/auto-complete here) to do "git submodule update --init lib/fuzzy". > 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! This is not the only way, see above. Patches to update submodules across nested submodules are welcome. > 8. Okay, now I want to execute a 'git submodule foreach' on just those > three submodules. Seems impossible. What about 'git submodule foreach --recursive .elisp/auto-complete'? Or - if that is your only populated submodule - a simple 'git submodule foreach --recursive' will do it too. > 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 ... and check out some arbitrary commit which most probably doesn't match what is committed in their superproject .elisp/auto-complete. You asked for it ... > 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? Thought about stepping into .elisp/auto-complete and doing a diff there to see what is modified? What does 'git status --recursive' show? > 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? By simply committing .elisp/auto-complete? Unless you record a submodule commit in its superproject, there is nothing to commit, right? > What is going on, seriously? Pilot error, mostly omitting the --recursive option and some - fixable - usability issues. Patches welcome. > This is just two levels of nesting: with more levels of nesting, > things only get worse. Yes, you cannot have the cake and eat it. Either you incorporate everything into a single repo (e.g. using subtree) and loose the strong distinction which content belongs to which upstream repo (which AFAIK is a valid choice unless you want to contribute back to the submodule's upstream) or you'll have to cope with the submodule borders showing up from time to time, reminding you which part of the work tree has another upstream. >>>>> 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. Yep, that's what I think too. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 22:57 ` Jens Lehmann @ 2013-03-26 7:57 ` Ramkumar Ramachandra 2013-03-26 16:57 ` Jens Lehmann 0 siblings, 1 reply; 18+ messages in thread From: Ramkumar Ramachandra @ 2013-03-26 7:57 UTC (permalink / raw) To: Jens Lehmann; +Cc: Git List 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 <repository> <path>'. 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-26 7:57 ` Ramkumar Ramachandra @ 2013-03-26 16:57 ` Jens Lehmann 0 siblings, 0 replies; 18+ messages in thread From: Jens Lehmann @ 2013-03-26 16:57 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Git List 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 <repository> <path>'. 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-24 17:38 Why does 'submodule add' stage the relevant portions? Ramkumar Ramachandra 2013-03-25 8:35 ` Jens Lehmann @ 2013-03-25 17:51 ` Junio C Hamano 2013-03-25 18:02 ` Ramkumar Ramachandra 2013-03-26 3:27 ` Duy Nguyen 2 siblings, 1 reply; 18+ messages in thread From: Junio C Hamano @ 2013-03-25 17:51 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Git List, Jens Lehmann Ramkumar Ramachandra <artagnon@gmail.com> 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 ;-). ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 17:51 ` Junio C Hamano @ 2013-03-25 18:02 ` Ramkumar Ramachandra 2013-03-25 18:20 ` Jonathan Nieder 0 siblings, 1 reply; 18+ messages in thread From: Ramkumar Ramachandra @ 2013-03-25 18:02 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git List, Jens Lehmann Junio C Hamano wrote: > Ramkumar Ramachandra <artagnon@gmail.com> 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 18:02 ` Ramkumar Ramachandra @ 2013-03-25 18:20 ` Jonathan Nieder 2013-03-25 18:27 ` Ramkumar Ramachandra 0 siblings, 1 reply; 18+ messages in thread From: Jonathan Nieder @ 2013-03-25 18:20 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Junio C Hamano, Git List, Jens Lehmann Ramkumar Ramachandra wrote: > Junio C Hamano wrote: >> Ramkumar Ramachandra <artagnon@gmail.com> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 18:20 ` Jonathan Nieder @ 2013-03-25 18:27 ` Ramkumar Ramachandra 2013-03-25 18:31 ` Junio C Hamano 0 siblings, 1 reply; 18+ messages in thread From: Ramkumar Ramachandra @ 2013-03-25 18:27 UTC (permalink / raw) To: Jonathan Nieder; +Cc: Junio C Hamano, Git List, Jens Lehmann Jonathan Nieder wrote: > Ramkumar Ramachandra wrote: >> Junio C Hamano wrote: >>> Ramkumar Ramachandra <artagnon@gmail.com> 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 18:27 ` Ramkumar Ramachandra @ 2013-03-25 18:31 ` Junio C Hamano 2013-03-25 18:48 ` Ramkumar Ramachandra 0 siblings, 1 reply; 18+ messages in thread From: Junio C Hamano @ 2013-03-25 18:31 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Jonathan Nieder, Git List, Jens Lehmann Ramkumar Ramachandra <artagnon@gmail.com> 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 18:31 ` Junio C Hamano @ 2013-03-25 18:48 ` Ramkumar Ramachandra 2013-03-25 18:50 ` Jonathan Nieder 0 siblings, 1 reply; 18+ messages in thread From: Ramkumar Ramachandra @ 2013-03-25 18:48 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jonathan Nieder, Git List, Jens Lehmann Junio C Hamano wrote: > Ramkumar Ramachandra <artagnon@gmail.com> 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 18:48 ` Ramkumar Ramachandra @ 2013-03-25 18:50 ` Jonathan Nieder 2013-03-25 19:06 ` Ramkumar Ramachandra 0 siblings, 1 reply; 18+ messages in thread From: Jonathan Nieder @ 2013-03-25 18:50 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Junio C Hamano, Git List, Jens Lehmann 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 18:50 ` Jonathan Nieder @ 2013-03-25 19:06 ` Ramkumar Ramachandra 2013-03-25 19:13 ` Jonathan Nieder 0 siblings, 1 reply; 18+ messages in thread From: Ramkumar Ramachandra @ 2013-03-25 19:06 UTC (permalink / raw) To: Jonathan Nieder; +Cc: Junio C Hamano, Git List, Jens Lehmann 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-25 19:06 ` Ramkumar Ramachandra @ 2013-03-25 19:13 ` Jonathan Nieder 0 siblings, 0 replies; 18+ messages in thread From: Jonathan Nieder @ 2013-03-25 19:13 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Junio C Hamano, Git List, Jens Lehmann 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Why does 'submodule add' stage the relevant portions? 2013-03-24 17:38 Why does 'submodule add' stage the relevant portions? Ramkumar Ramachandra 2013-03-25 8:35 ` Jens Lehmann 2013-03-25 17:51 ` Junio C Hamano @ 2013-03-26 3:27 ` Duy Nguyen 2 siblings, 0 replies; 18+ messages in thread From: Duy Nguyen @ 2013-03-26 3:27 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Git List, Jens Lehmann On Mon, Mar 25, 2013 at 12:38 AM, Ramkumar Ramachandra <artagnon@gmail.com> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2013-03-26 16:58 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-03-24 17:38 Why does 'submodule add' stage the relevant portions? Ramkumar Ramachandra 2013-03-25 8:35 ` Jens Lehmann 2013-03-25 8:59 ` Ramkumar Ramachandra 2013-03-25 18:43 ` Jens Lehmann 2013-03-25 19:57 ` Ramkumar Ramachandra 2013-03-25 22:57 ` Jens Lehmann 2013-03-26 7:57 ` Ramkumar Ramachandra 2013-03-26 16:57 ` Jens Lehmann 2013-03-25 17:51 ` Junio C Hamano 2013-03-25 18:02 ` Ramkumar Ramachandra 2013-03-25 18:20 ` Jonathan Nieder 2013-03-25 18:27 ` Ramkumar Ramachandra 2013-03-25 18:31 ` Junio C Hamano 2013-03-25 18:48 ` Ramkumar Ramachandra 2013-03-25 18:50 ` Jonathan Nieder 2013-03-25 19:06 ` Ramkumar Ramachandra 2013-03-25 19:13 ` Jonathan Nieder 2013-03-26 3:27 ` Duy Nguyen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).