On Tue, Jun 24, 2008 at 17:31, Klas Lindberg <klas.lindberg@gmail.com> wrote:
quoted text
>
>> 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.

quoted text
> 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/*.

quoted text
> 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.

quoted text
> 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?

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html