On Mon, Jan 13, 2014 at 02:13:46PM -0800, Junio C Hamano wrote: > "W. Trevor King" <wking@xxxxxxxxxx> writes: > > > Additional metadata, the initial checkout, and syncing down > > ----------------------------------------------------------- > > > > However, folks who do local submodule development will care about > > which submodule commit is responsible for that tree, because > > that's going to be the base of their local development. They also > > care about additional out-of-tree information, including the > > branch that commit is on. > > Well, please step back a bit. > > They do not have to care about what local branch they use to build > follow-up work based on that commit. They do if they want to checkout the banch out again later, before pushing it somewhere public. > In fact, they would want to be able to develop more than one > histories on top, which means more than one branches they can name > themselves. Agreed, bug for each superproject branch they will still have a single submodule branch that should be checked out by default when they checkout that superproject branch. > The only thing they care about is where the result of their > development _goes_, that is the URL and the branch of the remote > they are pushing back to. Maybe they're just doing local development? I think the remote branch(es) you pull from and push to are important, but not the only thing you might care about. > I have a feeling that this is not specific for submodules---if you > did this: > > git init here > cd here > git fetch $there master > git reset --hard FETCH_HEAD > > and are given the resulting working tree to start hacking on, you > would not know where the history came from, or where your result > wants to go. > > So "the branch that commit is on" is a wrong thing to focus on. > "The branch the history built on top of the commit wants to go" may > be closer and these two are different. That makes sense. I don't think the former (as distinct from the latter) is of any interest to anybody. I don't care what the branch name was when the past history was developed. I don't even really care about the new branch name. I do care that checking out a superproject branch gives me the same branch (with pull/push configs, etc.) that I had the last time I was on that superproject branch. > > For already-initialized submodules, there are existing places > > in the submodule config to store this configuration: > > > > 1. HEAD for the checked-out branch, > > 2. branch.<name>.remote → remote.<name>.url for the upstream > > subproject URL, > > 4. branch.<name>.rebase (or pull.rebase) to prefer rebase over merge > > for integration, > > 5. … > > What happened to 3 ;-)? I can't count? :p > In any case, "local-branch" is wrong from two aspects: > > 1. (obvious) It does not follow our naming convention not to use > dashed-names for configuration variables. I'll use localBranch in my mockup ;). Although skimming through config.txt shows a number of alllowercase settings as well as camelCase. > 2. You do not care about the names you use locally. The only thing > you care about is where people meet at the central repository, > i.e. where your result is pushed to. I also care about local-checkout consistency, as described above. > > Syncing up > > ---------- > > > > In the previous section I explained how data should flow from > > .gitmodules into out-of-tree configs. > > s/should/you think should/, I think, but another way may be not to > copy and read from there, which may be a lot simpler. Then upon > switching branches of top-level superproject (which would update > .gitmodules to the version on the new branch), you may get different > settings automatically. That only works for superproject-level commands that know about the .gitmodules file. If you cd into the submodule and work there directly, your actions will be using the submodule's out-of-tree config. I think most of the time folks will want those out-of-tree configs to match the settings in the superproject's .gitmodules, hence the submodule.<name>.sync defaulting to true. > > ... Since you *will* want to share the upstream URL, I proposed > > using an explicit submodule.<name>.active setting to store the “do > > I care” information [2], instead of overloading > > submodule.<name>.url (I'd auto-sync the .gitmodule's > > submodule.<name>.url with the subproject's remote.origin.url > > unless the user opted out of .gitmodules syncing). > > It may not be a good idea to blindly update to whatever happens to > be in .gitmodules, especially once submodule.*.url is initialized. Why not? We're blindly updating it to the value that was previously pulled out of the submodule's out-of-tree config. If the user doesn't like what's happening to .gitmodules upstream and doesn't want to keep a patched version locally, they can always turn off submodule.<name>.sync. > Imagine that your embedded appliance project used to use a submodule > from git://k.org/linux-2.6 as its kernel component and now the > upstream of it is instead called just git://k.org/linux; the URL > specified by submodule.kernel.url in .gitmodules for the entry > submodule.kernel.path=kernel would have changed from the former to > the latter sometime in the superproject's history. Switching back > to an old version in the superproject to fix an old bug in the > maintenance track of the superproject would still want to push > associated fixes to the kernel to k.org/linux, not linux-2.6, the > latter of which may now be defunct [*1*]. The checkout would work (because the old gitlinked commit is already in the local repository), but the push would not. I don't think it would be difficult to recover from that manually (and just specify the full URL when pushing). You could also: 1. Commit your fix. 2. Checkout a more modern superproject branch (which will load the current URL into the submodule's config). 3. Push the fix. 4. Continue to work on the modern branch. That doesn't sound much more difficult than the ideal: 1. Commit your fix. 2. Push the fix. 3. Checkout a more modern superproject branch (which will load the current URL into the submodule's config). 4. Continue to work on the modern branch. If you expect to be back making more superproject/subproject joint bugfixes in future, I think it makes sense to start a maintenance branch of the superproject that updates the .gitmodules URL to point at the modern location. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Attachment:
signature.asc
Description: OpenPGP digital signature