Am 13.12.2011 00:50, schrieb Phil Hord: > On Mon, Dec 12, 2011 at 5:29 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: >> Am 12.12.2011 22:16, schrieb Phil Hord: >>> I thought-experimented with this a bit last year and came to the >>> conclusion that I should be able to 'float' to tips (developer >>> convenience) and also to store the SHA-1 of each gitlink through >>> history (automated maybe; as-needed). >> >> Which means that after "git submodule update" floated a submodule branch >> further, you would have to commit that in the superproject. > > Sadly, yes. Currently I have my CI-server do this for me after it > verifies each new submodule commit is able to build successfully. Which I think is a good thing to do, as you have a good chance of catching breakage introduced by the submodule updates. "float-only" submodules won't always be a pleasant experience, as they can (and sometimes will) get you into trouble when advancing them introduces bugs (and then you can't even bisect that breakage). >>> The problem with "float + gitlinks", of course, is that it looks like >>> "not floating" to the developers (git-status is dirty unless >>> overridden, etc.) >> >> Yeah. But what if each "git submodule update" would update the tip of >> the submodule branch and add that to the superproject? You could follow >> a tip but still produce reproducible trees. > > Yes, and that's what I want. > > Not what it sounded like was being suggested before, which (to my > eyes) implied that the submodule gitlinks were useless noise. It was suggested in other threads in the past. For a start, you could write a script doing that and play around with it. And if that works well for you, we can discuss if implementing that functionality into "git submodule update" makes sense. -- 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