Re: git-switch(1) then git-pull(1)

On Dec 2, 2022, at 17:19, Graham Perrin <grahamperrin@freebsd.org> wrote:

> On 02/12/2022 12:08, Nuno Teixeira wrote:
>> Not sure if I understand but I use `git switch` on ports tree to switch from 'main' to 'quarterly' to avoid having 2 trees.
>> 
>> e.g.
>> When in main and need to do a commit on 2022Q4:
>> `git switch 2022Q4`
>> `git pull --rebase`
>> `git cherry-pick -x XXX`
>> `git push`
>> 
>> and switch back to main:
>> `git switch -` or `git switch main`
>> `git pull --rebase`
>> 
>> Hope that helps
> 
> There's the statement after the switch: 
> "up to date"
> If the branch is truly updated, then what are the subsequent updates? (The pull immediately after the switch.)

"up to date" is not explicit about what is up to date relative
to what else that is around in various places.

git switch is described via:

       Switch to a specified branch. The working tree and the index are
       updated to match the branch. All new commits will be added to the tip
       of this branch.

What is up to date is the working tree and index relative to the
.git/... vintage that you have and only the material from it for
that branch that you have switched to: no longe rmaterial from
the prior branch.

There is "git fetch" for updating the .git/... vintage without
updating any branches to use the new material. Various forms
of "git merge" does that second part --but only for one branch
at a time.

I'm not aware of a command that updates all branches all at once
to match the updated .git/... material, much less all working trees
and indexes as well.

"git pull" variants do both a "git fetch" and a "git merge" for
some branch. But it does not update the other branches to
track the updated .git/... material for them.

One does not normally deal with an overall global "up to date"
status in all respects for multi-branch git repositories. For
example, I deal with branches releng/13.* , stable/13 ,
and main [so: 14]. But I almost never do anything with any
of releng/12.* or stable/12: so, normally no merges for those.

I actually normally do fetch and merge separately, doing
multiple merges of multiple branches over some time after
the fetch. By the time I'm done, the freebsd repository
has probably been changed. Basically, rarely or never
"globally up to date in every respect" relative to the
FreeBSD repository and my local context, always just some
more specific, limited concept of "up to date" that is of
interest to me at the time.


===
Mark Millard
marklmi at yahoo.com