+972 52-548-6969
Git submodules & subtrees
time to read 2 min | 223 words
I am getting really sick of git submodules, and I am trying to find alternatives.
So far, I have discovered the following options:
- git subtree – a shell script that doesn’t work on Windows (https://github.com/apenwarr/git-subtree)
- Braid – a ruby script that fails to run on windows (https://github.com/evilchelu/braid)
PS C:\Work\RavenDB> braid add git@github.com:ravendb/raven.munin.git
F, [2011-01-09T18:41:09.788525 #224] FATAL -- : uninitialized constant Fcntl::F_SETFD (NameError)
C:/Ruby186/lib/ruby/gems/1.8/gems/open4-1.0.1/lib/open4.rb:20:in `popen4'
C:/Ruby186/lib/ruby/gems/1.8/gems/evilchelu-braid-0.5/lib/braid/operations.rb:103:in `exec'
C:/Ruby186/lib/ruby/gems/1.8/gems/evilchelu-braid-0.5/lib/braid/operations.rb:114:in `exec!'
C:/Ruby186/lib/ruby/gems/1.8/gems/evilchelu-braid-0.5/lib/braid/operations.rb:51:in `version'
C:/Ruby186/lib/ruby/gems/1.8/gems/evilchelu-braid-0.5/lib/braid/operations.rb:57:in `require_version'
C:/Ruby186/lib/ruby/gems/1.8/gems/evilchelu-braid-0.5/lib/braid/operations.rb:78:in `require_version!'
C:/Ruby186/lib/ruby/gems/1.8/gems/evilchelu-braid-0.5/lib/braid/command.rb:51:in `verify_git_version!'
C:/Ruby186/lib/ruby/gems/1.8/gems/evilchelu-braid-0.5/lib/braid/command.rb:10:in `run'
C:/Ruby186/lib/ruby/gems/1.8/gems/evilchelu-braid-0.5/bin/braid:58:in `run'
C:/Ruby186/lib/ruby/gems/1.8/gems/main-4.4.0/lib/main/program/class_methods.rb:155:in `run!'
C:/Ruby186/lib/ruby/gems/1.8/gems/main-4.4.0/lib/main/program/class_methods.rb:155:in `run'
C:/Ruby186/lib/ruby/gems/1.8/gems/main-4.4.0/lib/main/program/class_methods.rb:144:in `catch'
C:/Ruby186/lib/ruby/gems/1.8/gems/main-4.4.0/lib/main/program/class_methods.rb:144:in `run'
C:/Ruby186/lib/ruby/gems/1.8/gems/main-4.4.0/lib/main/factories.rb:18:in `run'
C:/Ruby186/lib/ruby/gems/1.8/gems/main-4.4.0/lib/main/factories.rb:25:in `Main'
C:/Ruby186/lib/ruby/gems/1.8/gems/evilchelu-braid-0.5/bin/braid:13
C:/Ruby186/bin/braid:19:in `load'
C:/Ruby186/bin/braid:19
- Piston – another ruby script that fails to run (http://piston.rubyforge.org/)
Does anyone know about a good solution that will work on Windows? Most specifically, I am looking for something that is plug & play, I don’t want to write code or to understand how git works. I just wanna it to work
Comments
This is one of the main reasons I use hg. It's Windows integration is just so much better - because it's not a ported linux tool but something that actually works on Windows natively.
If you're frustrated enough, I'd suggest trying hg - simply run hg convert and your repository will be converted in full (including history) to hg.
Re. the submodules, I think that's what mq does in hg and I know mq works very well; I'm just not sure what submodules actually does.
Good luck finding a solution, either way.
I spend about 2min per day in my source control program which is subversion. Even the effort of learning the most basic usage of git would trump any productivity gains for years. I doubt the gains are big but even for a 100% gain (2min/day) it would take years to amortize.
This is like learning a dynamic language in order to not need to write types. The reasoning about typing is correct but you lose other things like auto-completion, faster error correction cycles and refactorings.
Both cases are analogous because there is a correctly understood benefit but an even bigger disadvantage that has not been accounted for.
Sorry about derailing this discussion. I need to start blog to get my rants out.
I'm with configurator. Git is teh suck on Windows. Mercurial and TortoiseHG is definitely the way to go. You can get plugins to seamlessly connect to git repos. And it is so much less of a pain on Windows.
@tobi
Just like with dynamic languages, there are advantages to Git you are not taking into account. Git allows you to work in ways that subversion doesn't even comprehend. Yes, replacing subversion with Git, and using it exactly as before, would be a waste of time.
I have become an order of magnitude more productive after I truly learned to use Git. It took time to truly understand distributed source control, but it was worth it. Git allows you to do amazing things you wouldn't even consider possible in your current source control program.
I recommend you check out this tutorial:
http://hginit.com/00.html
It is for Mercurial, but it is applicable to Git as well. It goes into detail about why you would want to learn about Distributed Source Control.
I did check out hginit and read through it (without trying it myself). I understand that now different repo organization have become possible but it seems to me that the current svn standard of having one central repo with trunk test and live branches is perfectly fine. Nobody programs on planes (disconnected commits) and most projects don't have 1000s of contributors either (see linus and his lieutenants). My assessment is of course only applicable to in-house software development with a reasonably small team.
@tobi: I don't know, hg has been great on my current 2-man team. git has been (to a lesser degree because it's git) good on my previous project even though I was flying solo... I'm using hg to manage my personal projects now, especially - but not only - if I work on them from two computers. It's just so much better.
@Oren - it would be better if you'd asked for help stating your problem, instead of stating the way a certain solution failed for you.
Ken,
Sure, the problem is that I have a shared project (Raven.Munin) that is used by two other projects (RavenDB & RavenMQ)
I want to maintain that in both.
I sort of assumed that by mentioning submodules I already said that.
@tobi
Distributed Source Control is definitely more beneficial to large or geographically separated development groups (hence the massive use in OSS). But I have found it very useful for my small team and personal projects.
The ability to effortlessly merge is the real key. I can have a branch for each large feature being worked on, and bounce around from branch to branch depending on what I am working on. I find myself making a larger number of commits, based on the logical connection of edits, where I used to have roughly daily commits with CVS. My code history is much more organized, and it is actually useful when I try to go back and figure out why and how specific changes were made.
All of this makes code review and project management much easier.
I have also used the lessons I learned from Git in my own projects. The concepts of change-sets, distributed editing, and conflict management make some impossible problems tractable. And Git is a great example of how to do these things correctly.
I am exaggerating only slightly when I say that Git has changed my professional life.
To be blunt, if you truly believe the primary advantage of dynamic languages is to cut down on your typing, I don't expect you would grok the subtle advantages of Git. Your original analogy was truly apt.
You don't specify what you find lacing in git submodule support. However, if you want to try out subtree, try installing bash from gnuwin32.sourceforge.net/packages/coreutils.htm and creating a batch file to execute the script.
@Dan: You have a point with what you are saying. Probably the advantages are to be found in the details so without trying I cannot really join the discussion. I will now shut up until I used hg or git myself.
I had trouble groking hg's branches vs git's, I generally use feature branches and merge --no-ff in git. I didn't see a great way to maintain feature branch history in merging with hg, but perhaps I'm retarded.
I also wasn't super thrilled with submodules like Oren is talking about. I just ended up putting my shared libraries in their own repository and treating them as binary dependencies in my applications, it's a bit of a hassle though. :/
Can't you use package management, e.g. OpenWrap, make a wrap of munin and then depend on it in DB & MQ? You work on Munin, publish Munin to local rep, goto DB or MQ, update and presto you have the new stuff.
I want to maintain that in both.
@ayende: submodules sounds like it should work in this scenario. What issues are you running into that makes you sick of it?
I'd store Munin in a separate repository and use windows junctions to directly link to either the sourcecode or a binary file. windows junctions are great for this (equivalent of a unix file link). It comes down to you share on-disk but not in-repository. This actually makes sense because as you share it among multiple repositories: which one 'owns' it? You have to choose. By placing it in a separate repository, you make that choice: neither of the two using codebases 'own' it.
A binary dependency is likely better, because of the sharing of the using codebases.
@Dan: distributed SCC is still the same as centralized SCC: it's not a technical issue. I.o.w.: if you can write good software in a centralized SCC you can in a distributed SCC, it's not as if distributed SCC suddenly makes software development 'simpler' or 'possible', simply because it's an organisational issue: who does what.
Merging... yes some people have problems with that. I think it also comes down to what you want to do. If you for example do:
version 1 is released
branch v1 into v2 repository (svn makes no difference, but alas)
dev on v2 trunk
patch on v1 trunk
merge from v1 to v2. This is actually easy to do in svn and you can create a simple cmd with a svn command which specifies the starting revision when v2 was branched
v2 is released
branch v2 into v3 repository
dev on v3
patch on v2 and v1, merge into higher repo, so first merge v1 into v2, then v2 into v3.
Never had merge crap, other than the unavoidable conflicts you'll get with git/hg as well.
what goes wrong is when you dev in a branch and you want to merge back into a trunk. Don't do that. Make the branch you dev in the new trunk.
Frans,
The problem isn't how to manage that on my local machine, the problem is how to do that in a way that you can do that without extra steps.
Frans,
Or when using branching.
The only benefit I've seen that Git has over Subversion is that I don't have to be connected to a central repository to get the benefits of Version Control. I've run into situations using SVN where I have code that isn't finished but I want to check in, but cannot because it would then affect everyone else's code; with Git I could commit as much as I wanted to locally and it would never affect anyone until I packaged it up and pushed it.
That said, the main issue with Git is that it, and therefore it's extensions, comes from what could be definitely considered the anti-Windows crowd, so getting any extra features to work on Windows is a chore in and of itself.
Just to correct what I said earlier, mq is not an hg equivalent to submodules; I misunderstood the submodules docs completely when I first went over them quickly to find out what it does.
I still think hg is better for Windows users.
Comment preview