Hi,

I would like the opinion of those of you using rosinstall with git 
repositories, having a sufficient understanding of git for what follows.

As you may know, what git calls "branches" are mere pointers to commits 
that are quite volatile compared to what is called a branch in other VCSs.
rosinstall currently handles git branches a bit crudely, creating a 
tracking branch when checking out giving no version or a branch name, 
but checking out a repo without creating a branch when giving a tagname 
or SHA-ID. The tracking branch was created to avoid certain git user 
interaction to happen during rosinstall.
Switching remote branches or versions in git using rosinstall on the 
other hand usually involves deleting the current repo and checking it 
out again (with user confirmation), which should never be necessary.

So I tried to come up with a better way of handling this, described it here:
https://kforge.ros.org/vcstools/trac/ticket/1
albeit talking about the lower-level library vcstools, on which 
rosinstall is based.

The bottom line is that there are multiple ways rosinstall could handle 
things reasonably with git (and I am not sure those are all of them):
1. It could avoid to create or change any branch ever, working untracked 
all the time.
2. It could create tracking branches with the name of the remote branch 
and try to stay on them when moving up or downstream with rosinstall
3. It could create tracking branches that can only move forward with 
their remote branch
4. It could work on a (tracking) branch whenever you specified a 
(remote) branch name, and work untracked if you give anything else.

Option 1. Working untracked all the time makes writing the rosinstall 
code rather easy, but has some risk of developing users losing locally 
commited changes if they behave quite carelessly. It is very alien to 
how humans should use git.

Option 2. of Moving tracking branches up and downstream of the remote 
branch is more complicated code, but should works better with humans 
working within such a repository. Mostly consider the use case 
rosinstall a remote branch, make a change, (test it), commit and push 
it. Repeat.

Option 3. is a compromise for users who do not want local branches to 
wander back in time, pretty much as complex to code as option 2.

Option 4 is a compromise that is very close to the current rosinstall 
behavior, fixing some odd ends and naming local branches as their remote 
counterparts.

So my question is, do you prefer rosinstall with git to stay as it is, 
or behave differently?
And if the latter, which of the alternatives would you prefer?

cheers,
   Thibault