On Tue, Jun 24, 2008 at 17:31, Klas Lindberg <klas.lindberg@xxxxxxxxx> wrote: > >> Can you explain why you have to do it this way? Or the whole workflow? > > I am looking into the possibility of writing a tool that handles > configurations of trees. Maybe you should be using the plumbing commands. > 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"? Do you mean this? 1. You have a repository with different branches as: master tree1 tree2 .. 2. You want /path/to/tree1 to always checkout tree1 and the same for treeN Then 3. In /path/to/treeN/.. you do: $ git clone /path/to/repo treeN $ git checkout -b treeN origin/treeN 4. To keep uptodate: $ git pull 5. The branches for the other trees are always uptodate in origin/*. > The main stumbling block is actually that a lot of git commands have > side effects on the working tree (usually because they do something > with a "current" branch). Sure. So you have to choose those that don't have these "side effects", you have plenty of them, mainly in the low-level, plumbing commands. > In my mind, the user should be able to > select a configuration that effectively fast forwards branches in some > trees and resets branches in others -- all of it without touching any > working trees (unless there is an explicit checkout). Well, if you touch the current branch, for sure, you want to update the working tree. Maybe you want to keep your local branches up to date with respect their tracking branch? > The example in this case is that fetching tags to update a branch > isn't possible. 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. Santi -- 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
