Specific svn/git package update use case

[Simon Wright]

Great, that answers all my questions thank you very much!

Just need to wait for the package build process to run again (the last
status for 122amd64-default was stoped: crashed:) so that I can test
properly.

On 10/04/2021 1:20 am, Mark Millard via freebsd-ports wrote:
> Simon Wright simon.wright at gmx.net wrote on
> Fri Apr 9 10:12:04 UTC 2021 :
>
>> Excellent Mark, thank you, then that is exactly what I need, the git
>> equivilent of svn up -r xxxxxx ${portsdir}.
>>
>> And is there a need to do git-commit or git-merge to deal with the
>> 'detached HEAD' message or can I just suppress this? Any local
>> modifications live in an overlay for poudriere to use so there is
>> nothing unique in my /usr/ports and I only track main, no other branches.
>
> So far as I know, you could just ignore the messages about
> detached HEAD for your intended style of use, if I
> understand your usage correctly.
>
> You may have other git use besides FreeBSD ports (now or
> someday), so I'm cautious about claiming the specifics
> below are fully appropriate, but you could do something
> like:
>
> git config --global advice.detachedHead false
>
> to make detached HEADs status easier to ignore: no more
> messages, or at least in fewer contexts. (I'm unsure if
> it would disable git status reporting on the that
> specific type of status information.)
>
> As indicated already, you may want to periodically use
> git status to cross-check on if something unexpected
> happened in your use that should be cleaned up.
>
>> On 09/04/2021 1:23 pm, Mark Millard via freebsd-ports wrote:
>>> Simon Wright simon.wright at gmx.net wrote on
>>> Fri Apr 9 02:48:47 UTC 2021 :
>>>
>>>> I'm still not clear though whether checking out this commit brings in
>>>> all the commits from git clone to this one or only this commit. My
>>>> reading seems to say that this is *only* this one commit which is not my
>>>> need. Can anyone confirm this please?
>>>
>>> [My wording is not trying to be explicit about multi-branch
>>> merge points. Nor does it try to deal much with if you have
>>> local changes or staged changes in place at the time of the
>>> activity or if you have extra files not checked into git in
>>> the tree as well. And so on: a simple same-branch context.]
>>>
>>> A commit hash/id identifies everything on the branch at the
>>> time the commit finished, including what did not change
>>> compared to the prior commit on the branch. Checking out the
>>> commit spans all of it. Jumping forward (or backward) a bunch
>>> of commits on a branch does not require doing them one by one
>>> to get the net effect.
>>>
>>> You may want to inspect after checkouts (or similar activity)
>>> that "git status" does not display any surprises that need
>>> to be cleaned up in the local file system via some variant(s)
>>> of git restore or/and git clean or the like.
>
> ===
> Mark Millard
> marklmi at yahoo.com