41–46 of 46 posts
It appears that one of the solutions he recommends, git-subtree, is going to be merged into git soon: 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.
It appears that one of the solutions he recommends, git-subtree, is going to be merged into git soon: 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.
http://thread.gmane.org/gmane.comp.version-control.git/19648...
http://thread.gmane.org/gmane.comp.version-control.git/19560...
I've also tried and failed several times to use submodules. Live would be a lot easier for my situations if the parent could always point to the head of the child instead of a specific revision.
No it would not be a good idea for the submodules to be always pointing to the HEAD of their repos. It might make sense for syncing with some very stable external projects but that is a very limited use case. I need to have a consistent set of all the submodules I'm working with. I need to reliably get the exact same versions of all the modules in the big repository. This allows me to do a "git bisect" to search for…
Did you notice I specifically said "my situations"? I wasn't talking about your situations, and it appears that the existing mechanism suits your needs. It does not suit mine and has been so problematic that I had to abandon use of submodules.
Earlier quoted context omitted.
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...
If you ask me, it was the wrong choice. I work on a huge project that's hosted on Repo (full Android OS + big proprietary driver tree), and the lack of this feature has really cost me lots of time doing manual labor that could be automated. 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 prob…
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.
The problem in automatically running "git submodule update" is that it might require network access, which may be down and/or slow. And the latest head might not be compatible with the rest of your software. Since there is no smart way of managing these problems, it's best not to do that implictly.
It appears that one of the solutions he recommends, git-subtree, is going to be merged into git soon: 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.