On Fri, Aug 22, 2014 at 11:00 AM, Marc Branchaud <marcnarc@xxxxxxxxxxx> wrote: > A couple of years ago I started to work on such a thing ([1] [2] [3]), mainly > because when we tried to change to relative submodules we got bitten when > someone used clone's -o option so that his super-repo had no "origin" remote > *and* his was checked out on a detached HEAD. So get_default_remote() failed > for him. > > I didn't have time to complete the work -- it ended up being quite involved. > But Junio did come up with an excellent transition plan [4] for adopting a > default remote setting. > > [1] (v0) http://thread.gmane.org/gmane.comp.version-control.git/200145 > [2] (v1) http://thread.gmane.org/gmane.comp.version-control.git/201065 > [3] (v2) http://thread.gmane.org/gmane.comp.version-control.git/201306 > [4] http://article.gmane.org/gmane.comp.version-control.git/201332 > >> I think you're on the right path. However I'd suggest something like >> the following: >> >> [submodule] >> remote = <remote_for_relative_submodules> (e.g. `upstream`) > > I think remote.default would be more generally useful, especially when > working with detached checkouts. Honestly speaking I don't use default.remote, even now that I know about it thanks to the discussion ongoing here. The reason is that sometimes I push my branches to origin, sometimes I push them to my fork. I like explicit control as to which one I push to. I also sync my git config file to dropbox and I use it on multiple projects and platforms. I don't use the same push destination workflow on all projects. It seems to get in the way of my workflow more than it helps. I really only ever have two needs: 1. Push explicitly to my remote (e.g. `git push fork` or `git push origin`) 2. Push to the tracked branch (e.g. `git push`) I'm also not sure how `push.default = simple` conflicts with the usage of `remote.default`, since in the tracked-repo case, you must explicitly specify the source ref to push. Is this behavior documented somewhere? > (For the record, I would also be happy if clone got rid of its -o option and > "origin" became the sacred, reserved remote name (perhaps translated into > other languages as needed) that clone always uses no matter what.) > >> [branch.<name>] >> submoduleRemote = <remote_for_relative_submodule> > > If I understand correctly, you want this so that your branch can be a fork of > only the super-repo while the submodules are not forked and so they should > keep tracking their original repo. That's correct. But this is case-by-case. Sometimes I make a change where I want the submodule forked (rare), most times I don't. Sometimes I can get away with pushing changes to the submodule and worrying about it later since I know the submodule ref won't move forward unless someone does update --remote (which isn't often or only done as needed). > To me this seems to be going in the opposite direction of having branches > recursively apply to submodules, which I think most of us want. > > A branch should fork the entire repo, including its submodules. The > implication is that if you want to push that branch somewhere, that somewhere > needs to be able to accept the forks of the submodules *even if those > submodules aren't changed in your branch* because at the very least the > branch ref has to exist in the submodules' repositories. There are many levels on which this can apply. When it comes to checkouts and such, I agree. However, how will this impact *creating* branches? What about forking? Do you expect submodule forking & branching to be automatic as well? Based on your description, it seems so (although a new branch doesn't necessarily have to correspond to a new fork, unless I'm misunderstanding you). This seems difficult to do, especially the forking part since you would need an API for this (Github, Atlassian Stash, etc), unless you are thinking of something clever like local/relative forks. However the inconvenience of forking manually isn't the main reason why I avoid forking submodules. It's the complication of pull requests. There is no uniformity there, which is unfortunate. Recursive pull requests are something outside the scope of git, I realize that, but it would still be nice. However the suggestion you make here lays the foundation for that I think. > With absolute-path submodules, the push is a simple as creating the branch > ref in the submodules' "home" repositories -- even if the main "somewhere" > you're pushing to isn't one of those repositories. > > With relative-path submodules, the push's target repo *must* also have the > submodules in their proper places, so that they can get updated. > Furthermore, if you clone a repo that has relative-path submodules you *must* > also clone the submodules. > > Robert, I think what you'll say to this is that you still want your branch to > track the latest submodules updates from their "home" repository. (BTW, I'm > confused with how you're using the terms "upstream" and "origin". I'll use > "home" to refer to the repository where everything starts from, and "fork" > for the repository that your branch tracks.) Well, you get the updates you > want when your branch tracks a ref in the "home" repository. But when your > branch starts tracking a ref in another "fork" repository then you'll get the > submodule updates in that ref's history from that "fork" repository. My usage of 'upstream' and 'origin' were wrong. I don't use upstream anymore, based on the explanations I've received here. I use the following now: origin = my central repository (authoritative) fork = My fork of the central repo I like your idea of forking/branching on submodules being recursive based on the super repo, but I just don't see how this is possible. How would git tell github to fork, for example? And would that also work on Stash? > Once your branch is tracking the "fork" repository, if you do a pull you > won't get any submodule updates because the fork's branch hasn't changed. > You need to fetch (recursively) from the "home" repo to get the submodule > updates (assuming one of the "home" repo's branches has updated its > submodules). Then, with your branch checked out in the super-repo, if you > check out the latest refs in your submodules git will tell you that you have > uncommitted changes in your branch. The correct way to get submodule updates > into your branch is to commit them. Even though you're doing a pull/rebase, > there's nothing to rebase onto in the "fork" repository that has the updated > submodules. I like your ideas, assuming they are technically possible. They sound like great solutions for the long term. However for now, the whole process of working with remotes is very confusing. At first it was complicated when it came to triangle workflow. Mostly because the way you set push.default changes completely between the two, especially when combined with various workflows. Add on top of that the complexity of workflows for submodules, and it becomes a complete mess. Maybe for you guys who actively develop and understand git's internals it isn't so bad. However I don't have that domain knowledge, so I only have a "user" perspective on the matter. `remote.default` sounds nice but how do I use it based on my response in my first paragraph above? Thanks guys, this is great discussion. -- 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