On Sat, Nov 17, 2012 at 02:20:27PM -0500, W. Trevor King wrote: > On Sat, Nov 17, 2012 at 04:30:07PM +0100, Heiko Voigt wrote: > > > > (2) "git diff [$path]" and friends in the superproject compares the > > > > HEAD of thecheckout of the submodule at $path with the tip of > > > > the branch named by submodule.$name.branch in .gitmodules of > > > > the superproject, instead of the commit that is recorded in the > > > > index of the superproject. > > > > > > > > > > Hmm. ???git diff??? compares the working tree with the local HEAD (just a > > > SHA for submodules), so I don't think it should care about the status > > > of a remote branch. This sounds like you want something like: > > > > > > $ git submodule foreach 'git diff origin/$submodule_branch' > > > > > > Perhaps this is enough motivation for keeping $submodule_* exports? > > > > > > > and the option were called something like "--follow-branch=$branch", > > > > ??? > > > > I am not sure if hiding changes to the recorded SHA1 from the user is > > such a useful thing. In the first step I would like it if it was kept > > simple and only the submodule update machinery learned to follow a > > branch. If that results in local changes that should be shown. The user > > is still in charge of recording the updated SHA1 in his commit. > > I understand what you're warning against here, or what it has to do > with "git diff". Is there a not missing here? Reads somehow like that. What I am talking about is the suggestion of Junio. Instead of showing a diff if the SHA1 is different we show a diff if the checkout in the worktree is different from the tip of the configured branch. That would hide the fact that a submodule has changed during a submodule update operation. > > From what I have heard of projects using this: They usually still have > > something that records the SHA1s on a regular basis. Thinking further, > > why not record them in git? We could add an option to update which > > creates such a commit. > > I think it's best to have users craft their own commit messages > explaining why the branch was updated. That said, an auto-generated > hint (a la "git merge") would probably be a useful extra feature. I have the same opinion. Commits should always be created by humans so you have someone to blame/ask why. But I guess there are people that expect this to be automatic. One argument somehow goes along the lines: "I already created a commit in the submodule why do I need to create another one in the superproject? Just follow the HEAD revision!" They think in subversions "submodules" which are merely pointers to other svn repositories without any revision information. I am unsure if its good to support this the same way. Another use case is big projects that have so many submodules that creating superproject commits would create to much maintenance work. They want to have their integration server make those commits. That would already be supported with update checking out the branch tips and the commit is just one extra thing to do by the integration server. So I think it should be fine just to teach update to checkout the configured branch tips (or forward them to their tracking branch tips) and leave the rest to the user. Cheers Heiko -- 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