hoi :) On Wed, Nov 29, 2006 at 08:00:22PM +0000, Andy Parkins wrote:ess=20 s=20 =20 make=20 he=20 dule=20 What about: You decide to try something out quickly and create a new branch in the submodule. After you have verified that it works, you merge it to the submodules master branch and commit that to the supermodule. Not that complicated, isn't it? In fact, my current implementation does not even allow to change the branch name of the submodule which is tracked by the supermodule ;-). Please excuse that I am not an native english speaker and I may have caused some confusion here. That is exactly what I wanted to say. In the supermoduel you call update-index (with the submodule path as argument) to update the index of the supermodule. Just like normal files. Nothing new. This is handled in the next paragraph. The argument really is: HEAD always points to the checked out branch, so it really has a relationship to the working directory. Yes, it's not a real counter-argument, but it relativates the previous pro-argument. ne=20 that=20 yes, but luckily GIT branches are very flexible. I don't think it is that bad. You always know which branch in the submodule is the "upstream" branch which is managed by the supermodule. You can easily have several topic-branches and merge updates from the master branch. otherwise you always have to remember which branch holds your current contents from the supermodule. When viewed from the supermodule, you are storing one branch per submodule in your tree. =20 Suppose you are working on a complicated feature in one submodule. You create your own branch for that feature and work on it. Now you want to update your project, so you pull a new supermodule version. Now this pull also included one (for you unimportant) change in the submodule. I think it is more clear to update the master branch with the new version coming from the supermodule, while leaving your work intact (you haven't commited it to the supermodule yet, so the supermodule should not care about your changes, it's just some dirty tree). Then you can freely merge between your branch and master as you like and are not forced to merge at once. And perhaps you even do not want to merge at all, because you are on an experimental branch which really is mutually exclusive with the current supermodule contents. =20 what=20 Of course you know: git-status will tell it. This is no different to today, where you can commit while still leaving a part of the tree dirty. --=20 Martin Waitz
| Andrew Morton | Re: 2.6.24-rc6-mm1 |
| Glauber de Oliveira Costa | [PATCH 8/19] modify write_ldt function |
| Steven Rostedt | Re: Major regression on hackbench with SLUB |
| Satyam Sharma | Re: 2.6.23-rc4-mm1 |
git: | |
| Chris Ortman | [FEATURE REQUEST] git-svn format-patch |
| Bill Lear | Meaning of "fatal: protocol error: bad line length character"? |
| Scott Chacon | Git Community Book |
| Catalin Marinas | Re: [ANNOUNCE] pg - A patch porcelain for GIT |
| Richard Stallman | Real men don't attack straw men |
| frantisek holop | nptd regression in 4.2 |
| Kevin | uvm_mapent_alloc: out of static map entries on 4.3 i386 |
| Vim Visual | GRAPE cluster supercomputer + OpenBSD |
| John Stoffel | Re: [PATCH] LogFS take three |
| hooanon05 | [PATCH 62/67] aufs magic sysrq handler |
| Chris Mason | Re: [PATCH][RFC] fast file mapping for loop |
| Chris Mason | Re: [ANNOUNCE] Btrfs v0.12 released |
