{"thread":{"id":"43937","subject":"Re: Feature Request: Branch-Aware Submodules","startedAt":"2016-08-26T15:21:28Z","lastAt":"2016-09-01T11:34:54Z","messageCount":3,"participants":["Hedges Alexander","Jacob Keller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"300258","messageId":"51671371-C59A-4304-99B2-B2C2256C4001@student.ethz.ch","threadId":"43937","inReplyTo":"5EA7D232-5D41-4653-9E35-21C502C79C92@student.ethz.ch","subject":"Re: Feature Request: Branch-Aware Submodules","fromName":"Hedges Alexander","fromEmail":"ahedges@student.ethz.ch","sentAt":"2016-08-26T15:12:49Z","receivedAt":"2016-08-26T15:21:28Z","isPatch":false,"sender":{"key":"ahedges@student.ethz.ch","avatar":null},"body":"\n> On 25 Aug 2016, at 19:45, Stefan Beller <sbeller@google.com> wrote:\n> \n> +cc Jacob and Lars who work with submodules as well.\n> \n> On Thu, Aug 25, 2016 at 2:00 AM, Hedges  Alexander\n> <ahedges@student.ethz.ch> wrote:\n>> \n>> Right now updating a submodule in a topic branch and merging it into master\n>> will not change the submodule index in master leading to at least two commit\n>> for the same change (one in any active branch). This happened to me quite a few\n>> times. To a newcomer this behavior is confusing and it leads to unnecessary\n>> commits.\n> \n> So you roughly do\n> \n>   git checkout -b new-topic\n>   # change the submodule to point at the latest upstream version:\n>   git submodule update --remote <submodule-path>\n>   git commit -a -m \"update submodule\"\n>   git checkout master\n>   git merge new-topic\n>   # here seems to be your point of critic?\n>   # now the submodule pointer would still point to the latest\n> upstream version?\n> \n\nExcuse my poor wording above. The problem is the following:\n\n# assume a repo with a few branches and one submodules\ngit checkout -b new_feature\ngit commit -am \"some new commits\"\ncd submodule/path\ngit commit -am \"dirty hacking on a library\"\ncd ../..\ngit commit -am \"changes and update library\"\ngit status\n# all is well\ngit checkout master\ngit status\n# it says new submodule commits ??\ngit commit -am \"update library again…\"\ngit merge new_feature\ngit checkout old_feature_that_never_made_it\ngit status\n# still ???\ngit commit -am …\n\nNow reading the comments below, I overlooked git submodule update. I used update\nonly the first time after a clone with the init flag. As a remedy I could just\nrun git submodule update after every merge, but then I always get a detached\nhead which is also not ideal.\nThe second thing I overlooked is just merging without worrying about the git\nstatus telling me the repository is dirty. But here my muscle memory does a\ncommit when the repository is dirty, before running any other git commands.\n\nObviously, its confusing to people without a certain amount of experience.\n\n>> The proposed change would be to have a submodule either ignored or tracked by\n>> the .gitmodules file.\n>> If it is ignored, as for instance after a clone of the superproject, git simply\n>> ignores all files in the submodule directory. The content of the gitmodules\n>> file is then also not updated by git.\n>> If it is not ignored, the .gitmodules is updated every time a commit happens in\n>> the submodule.\n> \n> So\n> \n>   git -C <submodule-path> commit\n> \n> should trigger a commit in the superproject as well, that changes the gitmodules\n> file? What do you record in the git modules file that needs updating?\n> As the version is tracked via the gitlink entry, I do not see the\n> information that\n> needs tracking here?\n\nI guess nothing has to be done here. I mistakenly thought the .gitmodules stores\nthe SHA.\n\n> \n>> On branch switches the revision shown in the gitmodules from\n>> that branch is checked out.\n> \n> So you are proposing to put the revision into the gitmodules file?\n> That would be redundant with the actual gitlink entry in your tree.\n> (as shown via `git submodule status`)\n> What would happen if the recorded revision in the gitmodules file and the\n> gitlink are out of sync?\n> \n> Oh, are you just proposing to actually make `git checkout` aware of the\n> submodules? See[1]. I would welcome such a change and be happy th\n> \n> [1] https://github.com/jlehmann/git-submod-enhancements\n> which has some attempts for checkout including the submodules.\n> I also tried writing some patches which integrate checking out submodules\n> via checkout as well. A quicker `solution` would be a config option that\n> just runs `git submodule update` after each checkout/pull etc.\n> \n\nI see. The quick fix is almost what I’m looking for, except that it leaves\nthe repo in a detached head state. Could the submodule update be made \nautomatically and intelligently pick the branch?\n\n> \n>> This change would have submodules conceptually behave more like files to the\n>> superproject.\n>> \n>> \n>> Like current behavior, git status would display whether the submodule has\n>> uncommitted changes or is at a new commit.\n> \n> See config options diff.submodule and status.submoduleSummary.\n> \n\nI meant that git status works fine the way it is implemented right now.\n\n> \n>> \n>> I couldn't find any discussions on the initial implementation of git-submodule\n>> or any previous proposals related to this in nature due to gmane being down\n>> right now and the mailing list archives on the other sites are not great for\n>> searching. So please excuse me if I'm bringing up already discussed stuff.\n> \n> https://public-inbox.org/git for reading on the web, or\n> \n>   git clone https://public-inbox.org/git\n> \n> for reading offline.\n> \n\nThanks.\n\nBest Regards,\nAlexander Hedges\n\n"},{"id":"300402","messageId":"CA+P7+xqA_3a8EPZ=2Y5pgkL+N=_F1v5pfyzErwest9aoKZC37w@mail.gmail.com","threadId":"43937","inReplyTo":"51671371-C59A-4304-99B2-B2C2256C4001@student.ethz.ch","subject":"Re: Feature Request: Branch-Aware Submodules","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-08-29T02:17:45Z","receivedAt":"2016-08-29T02:18:12Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Fri, Aug 26, 2016 at 8:12 AM, Hedges  Alexander\n<ahedges@student.ethz.ch> wrote:\n>> On 25 Aug 2016, at 19:45, Stefan Beller <sbeller@google.com> wrote:\n>> [1] https://github.com/jlehmann/git-submod-enhancements\n>> which has some attempts for checkout including the submodules.\n>> I also tried writing some patches which integrate checking out submodules\n>> via checkout as well. A quicker `solution` would be a config option that\n>> just runs `git submodule update` after each checkout/pull etc.\n>>\n>\n> I see. The quick fix is almost what I’m looking for, except that it leaves\n> the repo in a detached head state. Could the submodule update be made\n> automatically and intelligently pick the branch?\n>\n\nYou probably want \"git submodule update --rebase\" or \"git submodule\nupdate --merge\" See git help submodule under the update section, or\neven a custom command variant where you can write your own bit of\nshell that does what your project expects.\n\nThanks,\nJake\n"},{"id":"300792","messageId":"AAED3CA2-3BDA-49CF-8930-FBC96F1EFE34@student.ethz.ch","threadId":"43937","inReplyTo":"CA+P7+xqA_3a8EPZ=2Y5pgkL+N=_F1v5pfyzErwest9aoKZC37w@mail.gmail.com","subject":"Re: Feature Request: Branch-Aware Submodules","fromName":"Hedges Alexander","fromEmail":"ahedges@student.ethz.ch","sentAt":"2016-09-01T11:34:28Z","receivedAt":"2016-09-01T11:34:54Z","isPatch":false,"sender":{"key":"ahedges@student.ethz.ch","avatar":null},"body":"Since I don’t want to change any history in the subproject, to me the most \nexpected behavior would be:\n\ngit submodule update —-recursive\n\nwith submodule.*.update set to the command:\n\n```\n#!/bin/bash\n\nbranches=`git branch --points-at \"$1\"`\n\nif [ ! $branches ] ; then\n    git checkout \"$1\"\n    echo \"do normal checkout\"\nelse\n    points_to_master=\n    other_branch=\n    for b in $branches ; do\n        if [ \"$b\" = \"master\" ] ; then\n            points_to_master=\"true\"\n        else\n            other_branch=\"$b\"\n        fi\n    done\n    if [ points_to_master ] ; then\n        git checkout master\n    else\n        git checkout \"$other_branch\"\n    fi\nfi\n```\n\nNow, this is not perfect and I’m sure I’ll refine it whenever I find it doesn’t\nsuit my needs, but I’m sure you can see the intentions here. I’m also not quite\nsure whether to prioritize tags over branches or the other way around.\n\nThanks for the suggestion. I hope this or a similar behavior could sometime\nbecome the default in git. Until the suggested quick fix will do for me.\n\nBest Regards,\nAlexander Hedges\n\n> On 29 Aug 2016, at 04:17, Jacob Keller <jacob.keller@gmail.com> wrote:\n> \n> On Fri, Aug 26, 2016 at 8:12 AM, Hedges  Alexander\n> <ahedges@student.ethz.ch> wrote:\n>>> On 25 Aug 2016, at 19:45, Stefan Beller <sbeller@google.com> wrote:\n>>> [1] https://github.com/jlehmann/git-submod-enhancements\n>>> which has some attempts for checkout including the submodules.\n>>> I also tried writing some patches which integrate checking out submodules\n>>> via checkout as well. A quicker `solution` would be a config option that\n>>> just runs `git submodule update` after each checkout/pull etc.\n>>> \n>> \n>> I see. The quick fix is almost what I’m looking for, except that it leaves\n>> the repo in a detached head state. Could the submodule update be made\n>> automatically and intelligently pick the branch?\n>> \n> \n> You probably want \"git submodule update --rebase\" or \"git submodule\n> update --merge\" See git help submodule under the update section, or\n> even a custom command variant where you can write your own bit of\n> shell that does what your project expects.\n> \n> Thanks,\n> Jake\n\n"}]}