On Mon, Jan 02, 2023 at 02:41:47PM -0700, Ted Bullock wrote:
> Hiya Folks,
> 
> I asked back in November about the preferred workflow for keeping
> abreast of a remote tree (like say the OpenBSD git mirror, or the GOT
> tree for instance). As a regular mortal man who toys with the tool once
> every month or so at the moment I regularly forget which commands are
> necessary to update each respective tree.
> 
> Since my muscle memory for the tool isn't super sharp, I'd say there is
> a command missing which wraps up everything into a little package.
> 
> For instance to update the GOT tree:
> 
> $ got fetch
> $ got update -b origin/main
> $ got rebase main
> 
> However the OpenBSD github mirror has different alias references and
> requires:
> 
> $ got fetch
> $ got update -b origin/master
> $ got rebase master
> 
> I guess the dilemma is that I forget that which tree has which
> references so every update in each tree I also have to run:
> 
> $ got branch -l
> 
> So I learn what the tree actually thinks it wants to use.  It's a little
> tedious and perhaps confusing; especially since I am using the software
> so casually at the moment. Again, notably the openbsd github mirror and
> GOT tree have different names.
> 
> It would be nice if I could specify a working branch for a given tree
> (perhaps at checkout time) and GOT would remember that without me
> needing to pull open the list of branches every time I want to sync to
> the latest code. Emotionally I think a vanilla `got update` with no
> qualifiers should do this by the way. But maybe I'm crazy? Dunno.
> 
> Thanks anyways folks.

There are vague ideas about providing an easier workflow for use by
developers who don't want to use local branches and instead commit
local changes in their work trees directly to the server.

By default, the fossil VCS attempts to sync changes between local and
remote repositories whenever a commit is created. This is in part what
inspired ideas about having an "easy" mode (which then may or may not
become the default mode of operation; time will tell).

Such a feature would likely help to address your concerns because the
above steps would need to be simplified, too. The interface might then
end up looking even more like CVS than Git. But I don't want to set any
command names in stone yet (it could be called "update", or it could be
called "pull", or be called something else entirely).

I have no idea if/when work on this would start, though.
At present my main goal is having a functional server implementation before
resuming work on other substantial features. If someone else wants to attempt
an implementation of "easy" mode I would be happy to discuss details. But I
would also like to avoid being derailed in terms of the time spent on all
of this.

For now, you could write shell scripts that call the above fetch/update/rebase
commands and name these scripts in a way that makes sense to you.