On 7/7/08, Sylvain Joyeux <sylvain.joyeux@xxxxxxx> wrote: > Yes, it fetches objects (admittedly, it updates something on the current > partition), but AFAIK does not change the state of the repository. So I thought > that it could be considered as a no-op from the repo point of view. The idea > behind the 'fetch' thing was to get the latest objects from the repository, > therefore being able to know the relationship between the currently committed > submodule state I haven't looked at your patch, so I don't know if you're calling fetch in such a way that it doesn't update any refs. Anyway, fetching is definitely not a no-op as far as the user is concerned. For example, if I'm on my laptop outside my company's LAN and I try to fetch, it might take 30+ seconds for fetch to time out waiting for our server. So it's not okay to fetch unless I specifically ask for a fetch. The trick here, I think, is that there's only one time the submodule should be linked to a commit you don't actually have. It should only happen if your parent module (supermodule) has been updated, but you haven't recently done a fetch in the submodule. Thus, I'd say the best fix would be to find a way to have "git pull" or "git fetch" in the supermodule also do a fetch in the submodule. I think it's fair to expect "fetchy" operations like fetch and pull to perhaps do some extra fetches, but not fair to expect "status" to do extra work like that. Also note that "your supermodule links to a commit that you haven't fetched yet" is a perfectly okay state to report to the user. I might use a "?" or something to indicate that. Have fun, Avery -- 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
