On Fri, Dec 25, 2020 at 12:13:51AM +0100, Christian Weisgerber wrote:
> Over on freebsd-git@freebsd.org I wrote:
> 
> > Update your source:
> > $ cd /usr/src
>   $ got fetch -a
> > $ got update -b origin/stable/12
> > $ got rebase stable/12
> > 
> > This is the standard configuration which allows you to have changes
> > on a local branch distinct from the upstream origin/* one.
> 
> Something I'm still not clear on: Where do I keep local changes?
> 
> origin/foo and foo are effectively different branches, so I guess
> I can just commit my local changes to foo.
> 
> Alternatively, I can create a local branch mystuff off foo, but then
> updating looks like
>   ...
>   update -b origin/foo
>   rebase foo
>   rebase mystuff
> 
> which seems redundant.
> 
> I can understand keeping foo and mystuff separate if I want to push
> changes on foo, but in a setup where you never push anything?

I tried two differents workflows with pros and cons on them. Both are
using mirror mode (what I am usually using).


1. mirror mode and do not commit anything

$ got br
master
$ got fetch
$ got update

it is simple, and work relatively well. the main drawback I saw when
uncommited stuff starts to be mixed purpose (wip bugs fixes + wip test
+ local commits + ...) as it is complex to separate the differents
works.

Ideally it should be one checkout per tasks, but for bigs checkouts
(as src/) it isn't necessary desirable.


For commiting something, it is creating a separated branch, stage
wanted changes and commit.

$ got br bugfix
$ got stage file1    # with -p if file1 contains bugfix + others things
$ got commit


2. local branch + rebase

it is what I am currently using.

$ got br
local
$ got fetch
$ got update -b master
$ got rebase local

Drawbacks:

- all files in local commits are modified (some 'make' will happily
  rerun all compilation - I am workaround that with ccache)

- rebasing mean losing some commits attributes which could be
  interesting (like the original date of the commit)

- if there is uncommited changes, 'got update' will change the branch
  (and possibly merge uncommited + master), but 'got rebase' will
  fail. Going back to 'local' (with 'got update -b local') is annoying
  (operation could be long as the worktree is big) and could possibly
  garbage some of uncommited changes.

- 'got histedit' is need to cleanup the local commits list:
   $ got update -c basecommitid
   $ got histedit
   fold / delete / ...

   finding the basecommitid could be annoying (as I am using mirror
   mode 'master' reference is changing on 'fetch'). usually I am using
   histedit after rebasing (so I could use 'got up -c master' to just
   to the common commit while keeping 'local' branch)


When I want to commit something, I am creating a separated branch, and
I am using cherrypick + commit.

$ got br bugfix
$ got cy commitid1
$ got ci


-- 
Sebastien Marie