On 4/30/08, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > On Tue, 29 Apr 2008, Tim Harper wrote: > > > 1) The submodule stays in the working copy when changing to a branch > > that does not have a submodule. This can break a build and cause > > problems. To work around, I have to delete the folder completely > > (git-clean). Then, when I switch back to the branch again, I have to > > re-download the submodule. > > The problem, of course, is that you can easily have valuable, but > not-tracked, files in there. Deleting the submodule is therefore no > option. I agree that blindly deleting isn't a good choice. For example, what if I've checked stuff into the submodule but never pushed it anywhere? Ugh. That said, it makes submodule folders act completely inconsistently with normal folders, which is highly undesirable. The current behaviour strongly encourages me to avoid submodules when I would otherwise like to use them, just to keep the rest of my team members (who are not git experts) from going insane. > But once you did "submodule init", you will never need to run it again, > since it edits your .git/config, which does not change when switching > branches. Not true. If ".gitmodules" is different between branches, then .git/config will have the wrong information. I think this was the reason for the "read .gitmodules directly and don't worry about .git/config" discussion/patches earlier. > And as for "submodule update", I like the fact that the submodule is not > updated automatically. For example, when I actively develop a submodule, > but have to rebase the superproject, I would _hate_ it if the submodule > wass updated. Why? Every other folder in your entire project gets updated when you "git checkout". Why are submodules different? I can personally vouch that this is confusing for almost everyone I've seen who tried it. > The whole idea about submodules is that they are repositories of their own > right, and therefore the superproject should not mess with them, _unless_ > explicitely asked to, with "submodule update". I think perhaps this is the root of the problem; you're thinking of the superproject as (A) "a tool for helping me track multiple subprojects automatically", while I think most people (or at least I) think of submodules as (B) "folders that have their own series of commits and thus can be shared between projects." If you think of it as (A), it's inconvenient to have them shuffling around automatically. But if you're in the (B) camp, having it not update automatically seems insane. I actually don't know any use cases for (A). If my app depends on a library in a submodule, for example, and I switch to a branch of my app that uses a different version of the submodule, why would I ever *not* want the submodule to switch too? If it doesn't, it'll probably break the compile. > > 3) If I don't run "git submodule update", and carelessly run "git commit > > -a" or "git add .", I risk propagating a submodule version from > > another branch or undoing an important change. > > git commit -a is something that might make sense for newbies, but you > really should learn to use git add -p and commit without -a. This is a matter of opinion; pretty much every other major VCS does the equivalent of "git commit -a" when you commit, and most people don't seem to mind. It is therefore possible that git is the weird one, not every other VCS. In particular, in this case what git is doing is, "You checked out a new branch, but I don't really trust you, so I actually made this modification in your tree for you. Now if you commit, you can check in that change that I think you meant to check in." Wouldn't you expect "git checkout branch; git commit -a" on a clean tree to never commit anything? > > PITFALLS: > > pitfall) > > If you commit a change on a submodule that's not on a branch, auto-updating > > submodules will make it difficult to revive that change. > > > > workaround) > > Don't allow the user to commit unless they are on a branch. > > > > ... couldn't think of anymore. Anyone? We had some discussion on the list earlier about having submodule checkouts automatically acquire a branch name, so that commits don't get lost as easily. I was going to think about this more and eventually submit a patch, but I haven't gotten to it yet. Anyway, the idea is that you have a branch by default, so that you don't end up in the useless situation of not being on a branch, which encourages checking in without being on a branch, in the first place. Have fun, Avery -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
