Detached HEAD after initial `west fetch` about west HOT 11 CLOSED

@tejlmand @nashif @mbolivar @ulfalizer please let me know which option you think is better

from west.

I also think that detached heads are gross so -1 on option 1. We have enough commands already so -0.5 on option 3.

I like 2 of what's left. If it's deeply upsetting that fetch is a git term and we're doing something slightly different, we can rename it to west get. Only half-joking.

from west.

@mbolivar
My thinking re. west fetch was that it fetches upstream data and does nothing else, which is how git fetch works.

You start with a blank "meta" repository (like an implicit git init). Upstream data can be fetched into it with west fetch, and branches can be created and checked out with e.g. west checkout -b worky-work. To update a branch, you can use west pull and west rebase.

If a repository already exists, west fetch is perfectly equivalent to git fetch.

There's a risk that you stretch the metaphor too far though. This is definitely not obvious without docs, so we'd need those.

repo sync is nice in that no one would be surprised by it cloning stuff, even without docs.

One thing that we definitely need to do is to mention west branch super early on in the documentation.

from west.

@carlescufi
I was probably a bit overly negative earlier btw. west clone kinda would make sense within the metaphor if it creates a master branch in all the repositories.

Wondering at what point the metaphor would start to hurt more than help though...

from west.

One place where it breaks down at the moment is with west branch. In git, that'd create a branch pointing at the current HEAD commit. In west, it creates a new branch that tracks the manifest revision.

Bit worried that the metaphor will add confusion. Maybe the repo guys considered stuff like this a long time ago, ran into cases where it doesn't work too well, and switched to a more specialized command set.

I'm still wondering how hard it would be to hack repo to work alright on Windows. I haven't worked much with it, but it seems to have a ton of features that would probably take us years to replicate (especially as we'd re-make a bunch of mistakes they've already made and fixed). We should be careful so that this doesn't turn into an exercise in not-invented-here.

I had never worked with repo before working on the west stuff, so I just assumed there were problems with it that couldn't be fixed. Wondering if it's that bad though...

Still think we could build something alright, but something worth considering.

from west.

Ironically, Google seems to love mono-repositories by the way (whenever lots of tricky third-party stuff isn't involved, like in Android, I'm guessing): https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext

from west.

IMO the fetch command should act as git clone and get you to a state similar to when you first cloned a repo, followup commands can then be used to create a topic branch that can be pushed to a fork to create a pull request.
We should not try to implement the command based on what Git does, probably it will be wise to try and pick command names that are not git commands and that can be confused with what west is doing.
So my vote is to get to get rid of the detached HEAD and do what git clone does.

from west.

In that case we can settle with renaming west fetch to west get as suggested by @mbolivar so that people do not get confused.

from west.

In any case it's clear that detached HEADs are not acceptable after asking for feedback all around. I will wait for @ulfalizer to comment on this.

from west.

Planning to add a west clone that does west fetch + west branch <remote HEAD branch, usually 'master'> <repository> or the like. west fetch would still clone, but most people probably wouldn't notice.

That would keep the internals sane, plus people can get the detached HEAD if they really want to.

from west.

Done

from west.