# Fat Git



## Geezer (Oct 1, 2021)

Excuse the inflammatory title, this is about git.

We are in October now (I do know that I am ahead of UTC), and this should be the _fourth_ quarter. We are past the equinox.

When I do
`git -C /usr/ports switch 2021Q4`
I get
`fatal: invalid reference: 2021Q4`


----------



## SirDice (Oct 1, 2021)

Geezer said:


> Excuse the inflammatory title, this is about git.


I was about to say, Brits are going to have a field day with that title 

The 2021Q4 branch hasn't been made yet. Watch for the announcements on freebsd-ports. The branching isn't done automatically.


----------



## zirias@ (Oct 1, 2021)

Uhm well, from git-switch(1):
`THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.`

The canonical way to "switch" to a different branch in git is to just check it out. git-checkout(1) accepts a branch name as its positional argument. With the `-b` flag, the target branch is created.


----------



## Geezer (Oct 1, 2021)

Zirias said:


> Uhm well, from git-switch(1):
> `THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.`
> 
> The canonical way to "switch" to a different branch in git is to just check it out. git-checkout(1) accepts a branch name as its positional argument. With the `-b` flag, the target branch is created.



I have got devel/git, but I do not seem to have `git-switch` or `git-checkout`. Where are they from?


----------



## zirias@ (Oct 1, 2021)

Uhm. Clicking on the links _might_ clarify 

Those are just the manpages for the `git` subcommands. To make it explicit: you used git-switch(1). I'm telling you to better use git-checkout(1). It's just a remark and doesn't change anything about the new quarterly branch not being there yet


----------



## SirDice (Oct 1, 2021)

You used the switch command with subversion to change to a different branch. That's probably where the confusion stems from. With git it's `git checkout <branchname>` to switch branches.


----------



## Tieks (Oct 1, 2021)

SirDice said:


> That's probably where the confusion stems from.


Could be from the Handbook, that mentiones _git switch_ too. Is it true that 2021Q4 starts exactly where 2021Q3 ended? For the ports tree there would be no need for a file update.


----------



## Jose (Oct 1, 2021)

`git switch` works just fine, despite the warnings on the man page. I use it all the time. They're finally trying to bring some sanity to the git-checkout mess. Use switch. It makes more sense.


----------



## Tieks (Oct 1, 2021)

Geezer said:


> fatal: invalid reference: 2021Q4


Use `cd /usr/ports && git branch -r` to see if it's already there.


----------



## SirDice (Oct 1, 2021)

Tieks said:


> Is it true that 2021Q4 starts exactly where 2021Q3 ended?


A new quarterly is always branched off from main aka latest.


----------



## zirias@ (Oct 2, 2021)

Jose said:


> `git switch` works just fine, despite the warnings on the man page. I use it all the time. They're finally trying to bring some sanity to the git-checkout mess. Use switch. It makes more sense.


As long as it's marked experimental, I won't. What's the benefit? And I don't think wording is that bad either (that is if you don't have very specific ideas what "checkout" means from other SCMs).

The only thing "messy" about git-checkout(1) is that it can perform two very different things. Guess that's why git-switch(1) and git-restore(1) were introduced and will probably replace git-checkout(1) one day. The warning doesn't say they don't work. It says to still expect breaking changes in their behavior.


----------



## Jose (Oct 2, 2021)

Zirias said:


> As long as it's marked experimental, I won't. What's the benefit? And I don't think wording is that bad either (that is if you don't have very specific ideas what "checkout" means from other SCMs).


I'm trying to get myself to use it because it makes more sense for newcomers who are used to "switch" from one branch to another. It also makes more sense as an English sentence. I'm used to the many meanings of "checkout", but that's not necessarily a good thing.



Zirias said:


> The only thing "messy" about git-checkout(1) is that it can perform two very different things. Guess that's why git-switch(1) and git-restore(1) were introduced and will probably replace git-checkout(1) one day. The warning doesn't say they don't work. It says to still expect breaking changes in their behavior.


Just two?

It's used to switch to an existing branch
It's used to create a new branch
It's used to revert changes in your working tree
It's used to merge
it's used to resolve conflicts
It's used to go into the Git Twilight Zone, AKA "detached head" state
Edit: and none of these maps to what "checkout" means in centralized SCMs: "Check out a working copy". That makes more sense both as an English sentence and conceptually as something you would do with an SCM.


----------



## zirias@ (Oct 2, 2021)

Jose said:


> I'm trying to get myself to use it because it makes more sense for newcomers who are used to "switch" from one branch to another. It also makes more sense as an English sentence. I'm used to the many meanings of "checkout", but that's not necessarily a good thing.


"many" == "two" here. Yes, separating them into two distinct subcommands seems like a good idea, I didn't object to that. I just won't use it as long as it's marked experimental. Nothing worse than having to re-train muscle memory, should they really introduce breaking changes 

Btw, "check out" is fine as long as you don't expect it to be the same as in other SCMs. As for english meaning, with git, it just refers to "checking out" files from the (local) repo to your working copy. Checking out a branch (or commit, e.g. by hash) corresponds to checking out lots of files in a single operation 



Jose said:


> Just two?


I'd say so, but


Jose said:


> It's used to switch to an existing branch
> It's used to create a new branch


you could argue indeed whether that's conceptually the same or not. There's no "right" or "wrong" here, though.


Jose said:


> It's used to revert changes in your working tree


by checking out a single file from the repo…


Jose said:


> It's used to merge


Only as a consequence of checking out a branch


Jose said:


> it's used to resolve conflicts


Only if you want to resolve it by, uhm, checking out the original version of that file


Jose said:


> It's used to go into the Git Twilight Zone, AKA "detached head" state


In git, a "branch" is just a persistent reference to an individual commit (and all of its child commits). So it makes sense that you can use a commit without a branch as well. In fact, that's how you'd start a new branch from some commit "in the past". Yep, it takes some time to get used to this kind of thinking, but again, it makes sense (and is essentially the same thing as checking out a branch, which translates to checking out its "HEAD" commit).

BTW, taking this last point into consideration, I actually don't think `switch` is the perfect name for that functionality in git. Think "switch" to a specific commit? Sounds slightly weird…

*edit:* all that said, yes, there's still a conceptual difference between "checking out" a commit (or branch) to "checking out" an individual file from whatever the current local HEAD points to. So yes, I still agree it's a good idea to separate them into two different subcommands


----------



## grahamperrin@ (Oct 3, 2021)

SirDice said:


> Watch for the announcements on freebsd-ports.



New 2021Q4 branch


----------

