> On 25 Aug 2016, at 19:45, Stefan Beller <sbel...@google.com> wrote: > > +cc Jacob and Lars who work with submodules as well. > > On Thu, Aug 25, 2016 at 2:00 AM, Hedges Alexander > <ahed...@student.ethz.ch> wrote: >> >> Right now updating a submodule in a topic branch and merging it into master >> will not change the submodule index in master leading to at least two commit >> for the same change (one in any active branch). This happened to me quite a >> few >> times. To a newcomer this behavior is confusing and it leads to unnecessary >> commits. > > So you roughly do > > git checkout -b new-topic > # change the submodule to point at the latest upstream version: > git submodule update --remote <submodule-path> > git commit -a -m "update submodule" > git checkout master > git merge new-topic > # here seems to be your point of critic? > # now the submodule pointer would still point to the latest > upstream version? >
Excuse my poor wording above. The problem is the following: # assume a repo with a few branches and one submodules git checkout -b new_feature git commit -am "some new commits" cd submodule/path git commit -am "dirty hacking on a library" cd ../.. git commit -am "changes and update library" git status # all is well git checkout master git status # it says new submodule commits ?? git commit -am "update library again…" git merge new_feature git checkout old_feature_that_never_made_it git status # still ??? git commit -am … Now reading the comments below, I overlooked git submodule update. I used update only the first time after a clone with the init flag. As a remedy I could just run git submodule update after every merge, but then I always get a detached head which is also not ideal. The second thing I overlooked is just merging without worrying about the git status telling me the repository is dirty. But here my muscle memory does a commit when the repository is dirty, before running any other git commands. Obviously, its confusing to people without a certain amount of experience. >> The proposed change would be to have a submodule either ignored or tracked by >> the .gitmodules file. >> If it is ignored, as for instance after a clone of the superproject, git >> simply >> ignores all files in the submodule directory. The content of the gitmodules >> file is then also not updated by git. >> If it is not ignored, the .gitmodules is updated every time a commit happens >> in >> the submodule. > > So > > git -C <submodule-path> commit > > should trigger a commit in the superproject as well, that changes the > gitmodules > file? What do you record in the git modules file that needs updating? > As the version is tracked via the gitlink entry, I do not see the > information that > needs tracking here? I guess nothing has to be done here. I mistakenly thought the .gitmodules stores the SHA. > >> On branch switches the revision shown in the gitmodules from >> that branch is checked out. > > So you are proposing to put the revision into the gitmodules file? > That would be redundant with the actual gitlink entry in your tree. > (as shown via `git submodule status`) > What would happen if the recorded revision in the gitmodules file and the > gitlink are out of sync? > > Oh, are you just proposing to actually make `git checkout` aware of the > submodules? See[1]. I would welcome such a change and be happy th > > [1] https://github.com/jlehmann/git-submod-enhancements > which has some attempts for checkout including the submodules. > I also tried writing some patches which integrate checking out submodules > via checkout as well. A quicker `solution` would be a config option that > just runs `git submodule update` after each checkout/pull etc. > I see. The quick fix is almost what I’m looking for, except that it leaves the repo in a detached head state. Could the submodule update be made automatically and intelligently pick the branch? > >> This change would have submodules conceptually behave more like files to the >> superproject. >> >> >> Like current behavior, git status would display whether the submodule has >> uncommitted changes or is at a new commit. > > See config options diff.submodule and status.submoduleSummary. > I meant that git status works fine the way it is implemented right now. > >> >> I couldn't find any discussions on the initial implementation of >> git-submodule >> or any previous proposals related to this in nature due to gmane being down >> right now and the mailing list archives on the other sites are not great for >> searching. So please excuse me if I'm bringing up already discussed stuff. > > https://public-inbox.org/git for reading on the web, or > > git clone https://public-inbox.org/git > > for reading offline. > Thanks. Best Regards, Alexander Hedges
