On Thu, Nov 03, 2022 at 04:43:34PM -0600, Ted Bullock wrote: > I'm curious about the expected workflow with got for keeping abreast of > a remote tree. > > For instance for got itself to stay up-to-date I use: > $ got fetch > $ got update -b origin/HEAD > $ got rebase main The above happens to work because origin/HEAD maps to origin/main. Specifying -b origin/main would be more explicit and prevent surprises in case the value of HEAD changes (which it generally should not, but who knows.) The HEAD symref is only used to determine a default branch to fetch or checkout in absence of arguments which specify a branch. This is Got-specific. Git uses HEAD for more things. > Is this correct or am I misreading the manual? I saw the mirror flag > exists for repositories but I don't think that quite is appropriate; > although I'm unclear when I would want that enabled or not. If you enable mirroring then 'got fetch' modifies references in refs/heads directly, so you can skip the rebase in the above example and just run 'got update' instead. So that step becomes a bit simpler. However, if you have local commits on any branch they will now collide with fetched changes from branches using the same name on server. Recovering from a branch name collision like that is not impossible but it could be a bit more difficult than rebasing branches. > I'm not doing day to day commits with the tool at the moment for any > projects beyond toying with it on this old sparc64 workstation. If I do > make a change though, I don't believe I'd want it to be over written by > the tool by default. I would recommend to enable mirroring only on repositories that sit on servers and receive changes only via the network, not from a 'got commit' command. Without mirroring enabled, branches in refs/heads are yours, and won't change during 'got fetch', and can be rebased after fetching as you described above.
workflow with got - November edition