31–40 of 46 posts
http://git.661346.n2.nabble.com/git-subtree-Next-Round-Ready...
This is excellent news. I've been using git subtree for a couple of years now without incident, and highly recommend it.
I've said this before but I'll say it again. Stay the hell away from Google's Repo tool. It's a half-baked badly maintained piece of ad-hoc software. It will completely destroy your git workflow. You'll also be married to the crappy review tool called Gerrit. Repo was made prior to Git submodules to do the exact same thing for Android. Now that Git has submodule support, Repo is useless. It does pretty much the same…
Repo seems to work the way it does on purpose: "...the reason we made repo was because we didn't want to deal with commits in the super project, or trying to merge concurrent branches in the super project. Instead we wanted each subproject to use a floating branch as the revision it is tracking." https://groups.google.com/d/msg/repo-discuss/ZpqOOE5mLXo/Sw0...
Another decision the Repo designers made that I disagree with is the silly Change-Id added to every commit message(!). Since when do globally unique identifiers (GUIDs) solve problems instead of creating more?
I've said this before but I'll say it again. Stay the hell away from Google's Repo tool. It's a half-baked badly maintained piece of ad-hoc software. It will completely destroy your git workflow. You'll also be married to the crappy review tool called Gerrit. Repo was made prior to Git submodules to do the exact same thing for Android. Now that Git has submodule support, Repo is useless. It does pretty much the same…
Well, since the maintainer of repo wants to kill it off, it is perhaps not surprising that it is badly maintained at the moment.
Very good article. The question is, will it ever be fixed? As it stands submodules don't even work sanely for the most trivial use-case of tracking a (slow changing) vendor-repo. Whoever designed this (Linus?) had a real brainfart here.
That is not the use case it was designed for. And submodules still work just fine for that. The fact that you have to do a separate submodule update does not make it broken. In fact, it makes it better when you start thinking about all the corner cases there are.
If you truly want to build a software out of subrepositories, you need to have a sane way of tracking working sets of revisions of all the submodules there are. And that is what git submodules does.
If you were blindly tracking the head of a repository, it would be useful _only_ for the use case you mentioned. Tracking slowly changing external vendor repos. That would be a whole lot less useful.
Submodules are pretty annoying if you modify the submodule repo a lot, but a pre-commit hook would help against the "forgot to push in submodule" issue, no?
However, most likely you don't want an automatic submodule update because of all the issues there are. It would only be useful for tracking a very stable slow moving external dependency.
Earlier quoted context omitted.
Well, since the maintainer of repo wants to kill it off, it is perhaps not surprising that it is badly maintained at the moment.
Do you have a source for that? If this information is true, I could use it to help convince our management at work that we should move off Repo and into Git submodules.
Also, if you do use Gerrit (even though you don't seem to like it) it has some better support for submodules from 2.3 onwards. See https://gerrit-review.googlesource.com/Documentation/user-su...
Very good article. The question is, will it ever be fixed? As it stands submodules don't even work sanely for the most trivial use-case of tracking a (slow changing) vendor-repo. Whoever designed this (Linus?) had a real brainfart here.
> As it stands submodules don't even work sanely for the most trivial use-case of tracking a (slow changing) vendor-repo. That is not the use case it was designed for. And submodules still work just fine for that. The fact that you have to do a separate submodule update does not make it broken. In fact, it makes it better when you start thinking about all the corner cases there are. If you truly want to build a softw…
Most people need only a fraction of that (akin to mercurial subrepo or even svn externals) and don't want to be exposed to all the corner cases and terrible usability.
Earlier quoted context omitted.
I think there's usefulness in being able to specify both things. I like the way it is now for a default, but like you say for some stable branch of another repository, it would be nice if submodules could be updated automatically.
You could specify a directory in .gitignore and create a script that clones/pulls the repository of your choosing into that directory.
Earlier quoted context omitted.
> As it stands submodules don't even work sanely for the most trivial use-case of tracking a (slow changing) vendor-repo. That is not the use case it was designed for. And submodules still work just fine for that. The fact that you have to do a separate submodule update does not make it broken. In fact, it makes it better when you start thinking about all the corner cases there are. If you truly want to build a softw…
The problem, as I see it, is that it was designed for a rather complex/obscure use-case. Most people need only a fraction of that (akin to mercurial subrepo or even svn externals) and don't want to be exposed to all the corner cases and terrible usability.
Managing software version dependencies is a complex problem and will inevitably have a complex solution, you can't make it any simpler by dumbing it down. If it was simple, there would be even more annoyed people when Git takes a long time checking for new versions in external repositories when doing something unrelated. And finally when the "simple use case" of tracking the remote HEADs and silently updating would give you an incompatible set of dependencies, someone would get furious and write an angry blog post.
What most people are asking here (get rid of "submodule update") is solvable by adding a shell alias. Or with the .gitignore and simple clone method discussed in this thread.
I don't think "git submodule update" is terrible usability. Complaining about is like complaining about having to "git add" before a commit. Removing that feature would make git worse, not better (albeit a little simpler). And as said earlier, if you don't like the "usability" it's a matter of adding a shell or a git alias to do what you want.
having a controlled state for foreign repos is absolutely essential. having worked with all-in-one repos, where external stuff is thown in... then rots... submodules are a better way, making keeping external code up to date. simple yet controlled.