On Sat, Oct 29, 2011 at 5:49 PM, Thibault Kruse <kruset@in.tum.de> wrote:
> 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?

I have used git some with rosinstall and found the branch handling
quite confusing. So, I don't much like the way it works now.

I am not a git expert, and I don't know what option would work better.
My usage mostly involves checking out a branch (master by default),
then pushing and pulling changes.

Switching branches seems quite confusing (but I find git confusing anyway).
-- 
 joq