On Sat, Oct 29, 2011 at 3:49 PM, Thibault Kruse <
kruset@in.tum.de> wrote:
> 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.
I wondered why it was like that. What user interaction?
> 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.
Agreed
> 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.
'vcstool' strikes me as a better name for this utility than 'rosinstall'.
It is potentially much more widely useful than just in ros, and 'install'
isn't really to the point.
> 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?
random thoughts:
- One would generally prefer that things not be too clever. (options
2 and 3... Maybe I could be convinced that these are actually
simple.)
- I also find the automatic creation of branches that do not exist
upstream confusing.
- Git stanzas in .rosinstall files could contain more information,
e.g. name_of_local_branch:remote-treeish
- Local tracking branches with the same name as upstream branches
(option 4) seem unsurprising enough.
- If you work with git submodules, you end up with detached heads
fairly often, and these are not so hard to re-attach (option 1).
- the vcstool 'update' step shouldn't rebase, it seems to me: maybe
I've pushed changes someplace already, and post-rebase my commits now
have different hashes. If the merge isn't a fast-forward, or if the
checkout is dirty, maybe vcstool should just 'fetch', and the user
should merge.
Just thinking out loud. Thanks for digging in to this.
-t
(text/plain)