Le mercredi 03 août 2011 à 08:25 +0200, Heiko Voigt a écrit : > Hi Henri, > > On Tue, Aug 02, 2011 at 08:42:24PM +0200, Jens Lehmann wrote: > > Am 02.08.2011 14:19, schrieb henri GEIST: > > > Le lundi 01 ao??t 2011 ?? 21:39 +0200, Jens Lehmann a ??crit : > > >> Am 30.07.2011 23:55, schrieb henri GEIST: > > >>> I can not see the difference with a gitlink. > > >> > > >> Then you can just use a config file for that, no? ;-) > > > > > > Off corse, I immediately start to work on it. > > > > I'm looking forward to that! > > Before hacking away please share some design information about this. > Ok this is what I intend to do. I plan to use a config file containing lines like "path_to_poited_repo SHA1_of_intended_commit URL_of_origin" the URL part will not be required. this file will be a list of pointer to other project. I have plane to name the file ".gitdependencies" and put it at the root of the current repository. Then I will : 1) Adding to git-status the ability to scan this file and report : - if the repository pointed by the path does not exist - if the SHA1 of the current checkout of this repository mismatch. - if this repository content differ from its checkout. 2) Adding to git status the ability to say if the current checkout has the expected one in its ancestors. 3) Adding to git-add the ability to: - create/update this file when trying to add an external repository - giving up if it is not an external repository. - automatically add the dependency file as well. 4) Adding to git-rm the ability to: - remove lines in this file. - add the result to index. - maybe removing the complete file if it is empty. 5) Adding to git-reset the ability to: - reset those lines one by one. - adding the the file to the index. I think I will do those steps as separate commits because they can works independently. it just need you to do the unimplemented step manually until it is done. That is a first proposal, all your comment will be appreciate. > Another thing: > > It sounds like the workflow you want to achieve is similar to the one > the android developers are using. They have a lot of submodules which > need automatic updating. > > The last time I checked they used repo (similar tool to submodules) > together with gerrit. > > AFAIR they wanted to switch to submodules and have gerrit automatically > make the superproject commits for single submodule changes. Additionally > if a change involves multiple submodules the developer should be able to > tie them together using a superproject commit. > > Have a look over there whether that workflow might help you? I just add a quick look on the android web site and I did not understand what exactly repo do. All there documentation only say how to install it and checkout android but it dose not explain anything about repo itself. I will search more info about it. Henri GEIST -- 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