It shatters the "open file" analogy it's like changing the contents of your buffer without changing which file you're writing to. This is also why I don't like overloading with `git checkout. When you decide to edit a different file, and open it, technically there's two independent operations - switch which file handle you're writing to, and replace the contents of the buffer with the contents of the new file - but I seldom think of it this way (and I can't think of an editor that separates them). You've got the file on disk, and the version in your editor's buffer (working tree), and every time you save, you're making a commit (with `-amend`, on most filesystems).
I think the easiest way to explain is by analogy to editing a regular text file.
This is a really subtle difference, but the key is that checkout is one atomic operation. It's like your model, but also includes the state of the repo at that commit. I'll call it, "the checked-out branch" (or other, but let's leave out detached HEAD for simplicity).
#How to use bitbucket with coda 2 free
I've never written this particular part out explicitly, so please bear with me and feel free to suggest better names or phrasing. Yours is the technically correct version, but when I'm working, I introduce a small abstraction on top. Thank you for the edit this is where our mental models diverge.
#How to use bitbucket with coda 2 update
> HEAD means "the branch to update when a new commit is made I don't think I thought of this argument when I originally chatted in #git-devel, maybe I'll give it another try. If it were a flag on branch, you wouldn't need a separate flag, just `git branch -fs newbranch` (-s for -switch).Īctually, looking through the man page for `checkout` now, I see 4 other options I didn't know about (-t|-track, -no-track, -guess, -no-guess), apparently for the sole purpose of being used with -b. > If -B is given, is created if it doesn’t exist otherwise, it is reset. `git checkout newbranch` will fail (error: pathspec 'newbranch' did not match any file(s) known to git), because the regular version of the command involves operating on something that already exists.Ĭheckout's `-B` variant. `git branch newbranch` will gracefully fall back to creating a new branch at HEAD. What happens if you remove the flag? Put differently, how much does the flag change the semantics? I'm going to discuss mental models in a separate comment because they're actually more interesting and this comment is getting too long. Again it’s great but for whatever reason it just works poorly on ARM and the whole ecosystem is geared to x86 and it just goes and pulls the x86 images and then fails to run them. It’s great, but it’s so easy to run into configuration problems or poor documentation.ĭocker. I recently started using Gitkraken which allows you to pull changes WITHOUT needing to commit locally first because it uses stashes. It’s purposely archaic commands and syntax leads to too many accidents far too often. It’s login and identity and resource management is confusing, and apparently you need a chrome extension which adds a bunch of complicated options I don’t really understand just to be able to change roles. It’s UI is honestly baffling, it feels and looks like someone made it in a rush with jQuery and Bootstrap years ago. Just frustrating to use, poor UX, and slow.
0 kommentar(er)
