>> I am looking into the possibility of writing a tool that handles >> configurations of trees. > > Maybe you should be using the plumbing commands. Yes. It looks like it. >> For instance, I want the tool to be able to >> consume some version of a configuration and create, update or reset >> branches in other trees accordingly. > > What are the "other trees"? One tree tracks a configuration file that just contains specs for other trees. The idea is something like this: Given a refspec on the configuration tree, git-view the configuration file and use the contained refspecs to clone/pull/fetch/reset/whatever a bunch of other trees. Note that I'm not trying to solve the problem addressed by the submodules system in git; I need configuration management. > Maybe you want to keep your local branches up to date with respect > their tracking branch? Well yes, but that is only half of it. One of the scenarios I'm pondering is this: A user wants to take an old configuration based on tags and try some use case that breaks a newer configuration. After the checkout, the working trees will not be "on" any branches (what's the word for that?). Unfortunately, most people seem to think that everything in a VCS happens on a branch. A lot of people will incorrectly assume that they are still on their "working branch" because they didn't check out a different branch! They checked out a tag and, like myself, have muddy ideas about what that actually means in relation to branches. I'd prefer to not have to tell them to try git-lost-found on a 40 different trees to recover commits that they made on non-branches. I'll have to think more about this. It's not a functionality shortcoming, but a UI one. > I don't see the point updating a branch with a tag, but you can make a > tool to update a branch with a tag, see for example > contrib/examples/git-fetch.sh. Thank you. I'll have a look at that, but after our conversation I think I was mentally stuck in the land of some other VCS. I know perfectly well that a tag is not just a marker along some branch, but I realize now that I was thinking of it as if it was. /Klas -- 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
