Fat Git

Geezer

Geezer

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
 
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.
 
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 ;)
 
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.
 
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.
 
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.
Click to expand...
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.
 
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).
Click to expand...
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.
Click to expand...
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.
 
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.
Click to expand...
"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?
Click to expand...
I'd say so, but
Jose said:
  • It's used to switch to an existing branch
  • It's used to create a new branch
Click to expand...
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
Click to expand...
by checking out a single file from the repo…
Jose said:
It's used to merge
Click to expand...
Only as a consequence of checking out a branch
Jose said:
it's used to resolve conflicts
Click to expand...
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
Click to expand...
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 ;)
 
You must log in or register to reply here.
Back
Top