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.