checking out a commits on port quarterly branch

[Ulrich Spörlein]

Just to add, losing work in git is actually very hard. While it's true 
that committing to a detached head doesn't track the new commits in a 
permanent way, you can actually use `git reflog` to see everything that 
you checked out for the last 90d or so.

To me, resetting the index is a more scary proposition, because I've 
still not wrapped my head around how that works and what --hard does, 
etc.

Cheers
Uli

On Wed, 2020-11-18 at 18:42:09 -0500, Marc Branchaud wrote:
>Hi Dan,
>
>You're doing it right, assuming that you're not going to be adding any
>new work atop that checked-out commit.  Your working copy does indeed
>reflect the code as of commit 46433baae934d92698422495b72f811839caa1a9.
>
>I've found that the best way to think of git branches is simply as a
>label for a particular commit SHA ID.  Git has other ways of labeling a
>commit (notably tags, and you can actually create your own, separate
>sets of labels if you like).  Git internally calls these labels "refs".
>  The special thing about a branch "ref" is that, when you have the
>branch checked-out and create a new commit, git automatically updates
>the branch's label to refer to the new commit.
>
>But you can also checkout a commit using its SHA ID, as you did.  In
>this case you are not using a branch, so git is warning you that it is
>not tracking a name for any new commits you might create.  Git still
>lets you do anything you want in this "detached" state, with the caveat
>that if you make new commits then it's up to you to figure out how to
>keep track of them (SHA IDs being a bit hard to memorize).  BTW,
>checking out a tag also puts git into the "detached" state, because tags
>are considered static and so they do not get automatically updated when
>you add new commits.
>
>For regular development it's important to understand when you're in the
>"detached" state, because it's easy to lose your work.  Hence the big
>warning message (which you can disable).  But if you're just looking to
>build the code at a particular commit, you're fine being "detached" from
>any actual branch.
>
>		M.
>
>
>On 2020-11-18 5:30 p.m., Dan Langille wrote:
>> When FreshPorts processes a commit, it needs a working copy of the repo as it was at the time of that commit.
>>
>> I have this working on head. I am trying to figure out how to do that when the commit is on a branch.
>>
>> To get a copy of the branch, I do:
>>
>> $ git checkout branches/2020Q4
>> $ git branch
>>    branches/2020Q2
>>    branches/2020Q3
>> * branches/2020Q4
>>    master
>>
>> Next, I want the tree as it existed at commit 46433baae934d92698422495b72f811839caa1a9
>>
>> i.e. https://github.com/freebsd/freebsd-ports/commit/46433baae934d92698422495b72f811839caa1a9
>>
>> My first attempt is
>>
>> $ git checkout 46433baae934d92698422495b72f811839caa1a9
>> Note: switching to '46433baae934d92698422495b72f811839caa1a9'.
>>
>> You are in 'detached HEAD' state. You can look around, make experimental
>> changes and commit them, and you can discard any commits you make in this
>> state without impacting any branches by switching back to a branch.
>>
>> If you want to create a new branch to retain commits you create, you may
>> do so (now or later) by using -c with the switch command. Example:
>>
>>    git switch -c <new-branch-name>
>>
>> Or undo this operation with:
>>
>>    git switch -
>>
>> Turn off this advice by setting config variable advice.detachedHead to false
>>
>> HEAD is now at 46433baae934 MFH: r555565
>>
>> That "MFH: r555565' message indicates that I am at the right commit.
>>
>> Is this a concern?
>>
>> $ git branch
>> * (HEAD detached at 46433baae934)
>>    branches/2020Q2
>>    branches/2020Q3
>>    branches/2020Q4
>>    master
>>
>>
>> Am I doing this right?
>>
>> Thank you
>>
>>
>_______________________________________________
>freebsd-git at freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-git
>To unsubscribe, send any mail to "freebsd-git-unsubscribe at freebsd.org"