On Sat, Oct 29, 2011 at 3:49 PM, Thibault Kruse 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