On Fri, Dec 25, 2020 at 02:19:34PM +0100, Stefan Sperling wrote:
> > 
> > I tried two differents workflows with pros and cons on them. Both are
> > using mirror mode (what I am usually using).
> 
> Thanks for writing this up. It is very interesting to see how you are
> using this tool.
> 
> > 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.
> 
> Fully agreed. And mixing up changes is the only possibility in this case.
> This is just like having a read-only CVS tree in /usr/src and being stuck
> with cvs diff and patch(1).

Or use quilt on top of cvs^Wgot checkout to manage the patch list (it
is what I did when using this scheme) :)

> > 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)
> 
> This has been brought up before. In theory we could avoid changing the
> timestamp of files that have not been modified during rebase. In general,
> not updating timestamps on files can cause other problems such as mixing
> objects files compiled with different build configurations. So the next
> problem becomes keeping track of situations when you must run 'make clean'.
> 
> But if the current behaviour is too annoying we can try to change it.
> Are you often waiting for amdgpu or clang to compile because of this?

it hightly depends the kind of patches/work.

For example, I had a patch in src/sys/systm.h some times ago (change
in prototype of wakeup() to return the number of waked-up
processes). And I switched to different approch because of
recompilation of whole sys/.

currently, drm includes file are in my patch list :)

I am unsure of the feasibility of keeping timestamps. technically on
rebase, files *are* changed (first with 'got up -b master' where
patches are unrolled, and next on 'got rebase local' with patch
reapplied).

and forcing files to keep timestamp of the commit date will fool
make(1) when existing changes are older than the last build (due to
the following possible scenario: remote-commit/push + local-make +
local-fetch + local-rebase (integrating new changes from first commit)
+ local-make (missing changed files because commit-date is older than
first make).

> > - rebasing mean losing some commits attributes which could be
> >   interesting (like the original date of the commit)
> 
> It was done this way on purpose. Is keeping information about when
> a change was first committed to a local repo really interesting?

to remember the date on starting a work ? but it isn't really
important. I am writing comments in my code now :)

> Note that each commit contains two timestamps, for the author and committer.
> We could keep the author timestamp intact during rebase. But at present the
> only got command which displays this timestamp is 'got cat'.
> 'got log' will display both committer and author if name or email address
> does not match, but it completely ignores the author date.
> 
> > - 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.
> 
> Would you prefer 'got update -b' to fail if local changes are present?
> This could easily be done.

my secret dream would be to have something like 'got rebase -b master local'
to specify the base branch and have an atomic operation for rebasing.

> The current behaviour of 'update -n' was implemented before 'got branch'
> performed an implicit update of the work tree. It was intended to support
> this case:
> 
> $ cd /usr/src
> hack hack hack
> # hmmm... this change should be on a branch
> $ got branch foo
> $ got update -b foo
> $ got commit
> 
> Nowadays we don't need a separate 'update -b' step anymore because
> that step has now become an implicit part of 'got branch':
> 
> $ cd /usr/src
> hack hack hack
> # hmmm... this change should be on a branch
> $ got branch foo
> $ got commit
> 
> So I suppose we could now require a clean work tree for 'update -b'?
> One disadvantage is that if you start editing files on the wrong branch
> accidentally it becomes harder to commit local changes to the correct branch.

I feel that keeping flexibility is important.

> > - '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)
> 
> Hmmm. You could create 'backup' reference before fetching:
> 
>  $ got branch -nc master oldmaster 
>  $ got fetch
>  ...
>  $ got update -c oldmaster
>  $ got histedit
> 
> However, if this is only a problem in mirror mode, perhaps the answer
> is not to use mirror mode? :)
> Mirror mode is really intended for read-only mirrors.

it permits to avoid some synchronization between local and remote,
specially when my local 'master' branch is only the same than the
remote one.

I am using mirror mode for repositories I don't own. but if I checkout
a repository it is usually because I contribute to it (and so write
patch).

Thanks.
-- 
Sebastien Marie