Solved Switching from releng/13.0 to release/13.0.0

J

jcw

I'm still trying to get the hang of git. Rather than bore you with all the silly things I tried, I'll just ask this.

How do I switch my local repo from releng/13.0 to release/13.0.0?

It seems like this should be trivially easy. But I get conflicts that git tells me to manually resolve.

Regards,
Jason
 
There is no release/13.0.0 branch, it's a tag. And you don't want to switch your source to that. For 13.0-RELEASE you should follow the releng/13.0 branch. To switch branches use git checkout <branchname>, for example git checkout releng/13.0.
 
A long, long time ago, I started running only specific releases. That has been updated enough for me. When FreeBSD dropped a new minor version, I would sup everything and build world/kernel/ports in a marathon session and then let things sit until the next minor version dropped. I set my FreeBSD hobby aside for most of the SVN era and never did a minor version update then. Now I am trying to rejuvenate my hobby.

Is there a reason beyond, "You want the latest and greatest" for not wanting to switch my source to release/13.0.0?

Perhaps git doesn't like going backward. (kinda defeats the point of source control though, right?) Or maybe git only likes going backward along a branch. Or maybe if I wanted to go backward in time to 13.0.0, I should go backward to that reference which is git revision (ea31abc261ffc01b6ff5671bffb15cf910a07f4b ?) rather than the tag?

Some of the sources I've read made it sound like branches, revisions, and tags (references) could be used interchangeably. Is that correct?

I'm fully willing to admit major misunderstandings of git.

And thanks for the quick reply.
 
jcw said:
Is there a reason beyond, "You want the latest and greatest" for not wanting to switch my source to release/13.0.0?
Click to expand...
That's the wrong tag or branch to follow. You want to track releng/13.0 which will be 13.0-RELEASE plus any security patches that will eventually be released. The release/13.0.0 tag is more an administrative label, it's 13.0-RELEASE as it's released. It will never get any updates, that means no security patches either. Which is why you don't want to track it. When the time comes for 13.1-RELEASE then you'll need to switch to the releng/13.1 branch. The 'releng' moniker (it's short for RELease ENGineering) has been used when FreeBSD was still on CVS, it was used on SVN too and it's the same now for GIT. Nothing's changed in this respect.

jcw said:
Perhaps git doesn't like going backward.
Click to expand...
Just like any other VCS (Version Control System) you can jump to anywhere you like. That's the whole point of a VCS, to keep a history of changes and being able to look at each of the indiviual change (commit).

jcw said:
Some of the sources I've read made it sound like branches, revisions, and tags (references) could be used interchangeably. Is that correct?
Click to expand...
Sort of. Everything refers to one or more specific commits. They're just different ways of 'marking' or tracking those. With git you typically use branches to track progress in some direction. Revisions were something CVS and SVN had, git doesn't keep track that way. Tags are a way of marking files at a specific point in their history.
 
Pulling updates to the releng/13.0 branch is in fact what I want do, which is what I was trying to tell SirDice all along. :)

For posterity:

I've took what you said and looked at what I was doing a little closer.

One mistake was that I conflated stable/13 with releng/13.0. I don't want to track stable, but I had the mistaken notion the releng was stable. Not sure why I mixed that up. I do want to track releng/13.0.

The next mistake was this. I knew that a tag was just a point in time. I knew that a branch was a line of development with a history. I was still trying to treat a tag like a branch though. I could get the answer correct on a quiz, but then I totally misunderstood things in the same breath. This was a consequence of the "interchangeable" query above. A person might use a tag/branch/revision as an argument to a git command interchangeably, but the consequences vary.

A simple 'git checkout release/13.0.0' will let me build a bonafide 13.0-RELEASE which is what I want to do right now. If my git-fu is correct, releng/13.0 and release/13.0.0 are identical at the moment.

Why do I want to build a bonafide 13.0-RELEASE? Because reasons! This is a hobby after all.

I also didn't realize that I inadvertently created a local branch named "release/13.0.0" due to syntax errors. The existense of a local branch identically named to a remote tag caused a bunch of my confusion.

Thanks for the help.

Jason
 
You must log in or register to reply here.
Back
Top