git config pull.rebase true
    git config rebase.autoStash true

    git config --global pull.rebase merges

  git checkout -b new-branch

Could you say more about this? I use

  git checkout -b new-branch

Recently, in explaining this to a colleague who's relatively new to git, I think the "aha" moment came in realising that if you rewrite the history leading to commit X, you're really making new commit Y in addition to the old commit X - you're not changing X in to Y. Leaving a branch pointing at X is enough that git will keep it around after the history rewriting, in case you decide to do something with it later.

Funny thing, nowadays it's going to be deprecated in favor of:

    git switch -c newbranch

I actually popped on the git development irc channel a few months ago to make this suggestion. The two people I talked to (at least one of whom seemed to be a core developer, although I did not verify this) did not see how, if you're going to conflate the actions of creating a branch and checking it out, it makes more sense to do this as a flag on the primary action, branch creation.

They were nice enough to have an in-depth conversion with a complete newcomer, though, so it was not a negative experience overall. Maybe someone else could convince them :)

That said, I do vaguely recall this seeming weird at first.

---Succinct argument---

What happens if you remove the flag? Put differently, how much does the flag change the semantics?

`git branch newbranch` will gracefully fall back to creating a new branch at HEAD.

`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.

---Less succinct further argument---

checkout's `-B` variant. Here's how the man page explains it:

> If -B is given, <new_branch> is created if it doesn’t exist; otherwise, it is reset. This is the transactional equivalent of > > $ git branch -f <branch> [<start point>] > $ git checkout <branch>

If it were a flag on branch, you wouldn't need a separate flag, just `git branch -fs newbranch` (-s for --switch).

Actually, 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.

---

I don't think I thought of this argument when I originally chatted in #git-devel, maybe I'll give it another try.

Thank you for the edit; this is where our mental models diverge. Yours is the technically correct version, but when I'm working, I introduce a small abstraction on top. I've never written this particular part out explicitly, so please bear with me and feel free to suggest better names or phrasing.

I'll call it, "the checked-out branch" (or other <tree-ish>, but let's leave out detached HEAD for simplicity). It's like your model, but also includes the state of the repo at that commit. This is a really subtle difference, but the key is that checkout is one atomic operation.

I think the easiest way to explain is by analogy[0] to editing a regular text file. 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). 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).

This is also why I don't like overloading with `git checkout <commit> -- <files>...`, which does not update the HEAD. It shatters the "open file" analogy; it's like changing the contents of your buffer without changing which file you're writing to. In my mind, that's a totally separate function (typically accomplished by opening the other file separately and then copying its contents into the buffer, an inefficient operation that I'm grateful git provides a better alternative to).

Aside, I also prefer to think of each branch (not commit!) as having its own persistent working tree and staging area; I'd prefer not to have to push and pop a stash each time I check out a new branch if I already had some work in progress. `git worktree` comes close, but lacks the ability to navigate between worktrees but stay in the same directory relative to the root, like `checkout` does. Also you have to initialize other worktrees with a different root, which pollutes the file system or forces you to use an extra level of nesting.

It's been on my list of projects for a while to write a git porcelain that works the way I'd like, but it's pretty low priority (despite my complaints, git works pretty well for me), so I doubt I'll get to it for a few years.

[0] Come to think of it, maybe "analogy" is not the best word. It's more like, I prefer to view git as an extension of my filesystem, so I want a consistent mental model across the whole thing.

It seems like the conflict is that there actually are some separate things going on "under the hood", and you're not satisfied with the way that git has combined them? To be explicit, some distinct steps we're discussing are:

1) Update the working tree to match the tree-ish

2) Create a new branch

3) Update HEAD to point at the branch (or other tree-ish)

As is currently implemented, "git checkout somebranch" does 1 and 3, "git checkout somebranch -- <files>" does just 1, "git branch somebranch" does just 2, and "git checkout -b newbranch" does 2 and 3. AFAIK, there's not a "git branch" argument that causes it to update HEAD, but the standard version of "git checkout" does exactly that. From the perspective of a new git user, maybe "git branch" is the obvious command to look at for making and using a new branch, but I think "git checkout" is the obvious command for using a branch.

So, perhaps "checkout" could have a better name; maybe "use" or "work" instead?

I must admit that I don't understand what you mean by "state of the repo at that commit" - is that related to the idea of each branch having a persistent working tree and staging area? When I run in to a situation where the second would be relevant, I tend to do "git commit -am WIP" then on return to that branch, "git reset HEAD~1". It very rarely happens that I'm in the middle of composing a commit (staging things) but need to switch to a different branch in the same project, so it doesn't really matter that the staging area and working directory all got munged together.

First, I would like to re-order those steps (and I am curious whether you intended the order to be meaningful). Then, I'll try to explain how they, while technically correct (again) to the best of my knowledge, don't match my mental model (particularly "update working tree", which is not part of "checkout" in smichel17-land). Yes — this is related to the "persistent working tree" (or maybe "working tree as a concept that doesn't exist in my mental model" would be better phrasing — but I'm getting ahead of myself).

---

Note that without flags, you'd have to "git branch" first, then "git checkout". Also, it's easier for me to think about if each command only performs consecutive steps, in order. Fortunately, we can achieve that:

1) Create a new branch

2) Update HEAD to point at the branch (or other tree-ish)

3) Update the working tree to match the tree-ish

"git branch somebranch" does just 1, "git checkout -b newbranch" does 1 and 2, "git checkout somebranch" does 2 and 3, "git checkout somebranch -- <files>" does just 3. I think this helps clarify my issues with both -b and --. They both change which step "checkout" starts on (and "-b" changes the ending, too!).

By analogy: if these commands are like functions, adding a step afterward is like a flag that modifies the output, while adding a step before is a flag that modifies the expected input. Sure, you could organize your code around the outputs it produces, and sometimes we do that (eg, serialization/parsing you have things like JSON.stringify, String.fromInt, different constructors for classes, etc). But typically it makes more sense to group based on what you want to do with a given object/class/data-type — it's nice to be able to answer, "I have an X, what are all the things I can do with it?"

Maybe that's stretching the analogy a little. But it ties in with my original comment mentioning the "primary action", which I guess I could rephrase as "first action in the chain".

---

What's the primary action of "checkout"? Well, "updating" the HEAD. So here's where we get back to abstractions / mental models — I would say, moving the HEAD. But first, let's take a short detour.

What's a commit? Technically, it's a diff and some metadata (author, parent commit(s), ...) with a deterministic name. But in terms of actual use, it's a snapshot of the repository at a certain point in time. (Or, if you'll permit a little snark, a version, as in "version control".) Zoom out to the whole repository, and you can visualize it as a tree of commits, ordered along the axis of time. Visualization:

    git log --graph --format="%C(yellow)%h%Cgreen%d"

Finally, back to the HEAD (our detour is over). Technically, it's just another tag. But to me, it's a camera, through which I look at a given box (or snapshot). It's the location where I am. It's $PWD.

To bring it all together:

- Branches sit on top of a commit and stay there.

- When I check out a different branch, they remain on top of the same commit, still holding the unsaved changes in their box. This is what I meant by "persistent working tree".

- Checking out a branch, conceptually, is just moving my view (HEAD) to a different branch. It doesn't involve changing files. It's the equivalent of "cd".

So this is why it barely makes sense for me to talk about "the" working tree. I have a bunch of boxes/folders/"working trees", called branches. That I have to copy them to "the working tree" in order to edit them is an implementation detail. Step 3 above (your 1, "update the working tree") doesn't exist in my mental model. You just move the HEAD. One atomic operation.

"-b" and "--" both break my mental model because they add side effects to an operation that's otherwise just "look around." "-b" isn't quite as bad, because I could imagine a flag on "cd" that makes it run "mkdir -p" first ("Go here, even if it doesn't exist yet."), but it still makes more sense as a flag on "branch" ("Create a new box, and look at it").

> So, perhaps "checkout" could have a better name; maybe "use" or "work" instead?

I think the new "switch" fits pretty well. And, "git branch [-s|--switch]" aren't taken yet :)

Aside, "git reset" is about moving which commit a branch sits on top of, and its various hardness flags are about what to do with the contents of both the box and the commits it was sitting on top of. There used to not be a command for "copy some stuff into my box from a different box or commit", so I had to use checkout, but now there's "git restore".

> What's the primary action of "checkout"? Well, "updating" the HEAD.

This might be where we diverge - I'd say that the primary action of "git checkout" is to update the working tree, secondary action is to update HEAD.

> What's a commit? Technically, it's a diff and some metadata (author, parent commit(s), ...) with a deterministic name. But in terms of actual use, it's a snapshot of the repository at a certain point in time.

This isn't actually the case; git commits contain a "tree", which is not a diff. The tree is a table of file paths, attributes, and hashes that each identify a "blob" - the (compressed) contents of a file. The commit represents a state of the committed files (and links); to me "snapshot of the repository" would include things like the state of the branches in the repo, HEAD, and commits that are present but outside the history of the commit in question.

---

Thanks for the explanation, I think I understand what you mean and like the idea. Maybe this is what you alluded to a few posts up, but it seems like a new subcommand could roll up the working directory and staging area in to a temporary commit or two, do the normal "git checkout otherbranch", then unroll any temporary commit(s) that were present in otherbranch.

At a previous employer, I used mercurial including a feature (perhaps provided by an extension, I can't find it at the moment) that allowed a commit to be marked as local-only, so it wouldn't be pushed. Something like this could probably be done with git hooks to prevent the temporary working/staging commits being shared unintentionally.

Why so? We don't go into great depth, but every hiring committee I've been on I make sure that we ask something about source control.

You can learn a lot about a developer's process by finding out if and how they use source control. (Red flag, for me, is if an apparent senior dev doesn't use a VCS.)

Red flag = warning sign, not anything related to Git flags.

OJFord is basically correct, though. It's 2020, so if you're interviewing for a developer/programming position, you should at least know something about the various VCS options.

If it helps, during our last set of interviews the question was "What is your strategy when using source control?"

Before that was the two part question of "Describe your preferred development environment, both physical and technical. What is one thing in your development process that you can’t live without?" (I always tell the candidate that my answer to this is some sort of VCS.)

(These were both for the second, in-person, interview. There's not necessarily a wrong answer. It's not like we're asking them to name as many differences between Git and TFS as they can. :) )

  git checkout -t remote-branch

I only had problems with errors from `e` on Windows - I'm guessing due to wrong line endings.

I was thinking the same for many years. But lately started to use VSCode for some projects. To see how staging is integrated there was almost an enlightening experience to be honest. All it takes to make staging an extremely useful feature, compared to all the other IDEs, is a slight change in how diffs are presented: In VSCode line-change markers indicate only a diff between working tree and cache (and not working tree and HEAD, like "everywhere" else). After staging a file in VSCode all inline diff markers disappear and the file looks like it would be unmodified. Than, new changes on top of the staged stuff will result in line change markers and inline diffs (showing only the unstaged changes). This way one can track "changes on top of changes" without having to commit the intermediate steps. This makes building up even big commits quite convenient as one can do it in small steps, having a (directly visible) diff of manageable size at any time in this process.

But it requires a lot of additional ceremony—alone naming the intermediate steps… ◔_◔

For once, it's a git command that seems to be clear about what it does, but it just doesn't check out.

Also, of late I have turned to "a lover of git GUI apps" form a full "git in cli is the best evangelist". But that has happened for most other tools as well. I guess I am kind of done with cli.

It loses all history of foo.bar. I guess if you pull up a version before the mv, you can still see it, but as far as git is concerned, foo.bar in the new location has no relationship to foo.bar in the old location.

Many people have complained about this over the years, but it's still that way. Because (they say) Linus likes it that way.

    git log --follow

Once you wrap your mind around what commits, heads and remotes are and learn to rebase you get an incredibly simple and fine-grained control. I never use stash because it's trivial to create a WIP commit and rebase later into the chunks I want to ship to permanent history.

Git is like a chef's knife: extremely powerful tool that's dangerous in untrained hands.

It's beyond ugly, it's needlessly incoherent. I use it because I have to and hate it. I've heard people say "the data model is a work of beauty". And I suppose that's true, but why have such a fucked up and confusing set of commands? Doesn't a "brilliant data model" deserve an equally brilliant command line?

The thing that saves git is that it works, and by some miracle, it is popular. People just memorize what they need to do for their workflows and that's mostly fine. Sometimes there's a screw-up and you blow time googling around or looking up fixes.

People won't publicly admit it but a lot of work gets trashed because finagling git intricacies is more painful than throwing away some work and starting over.

Probably because Linus Torvalds wrote it, and also because GitHub was actually quite a significant improvement over SourceForge. I know some people "love to hate" GitHub, but they made some really good "developer-first" UX improvements that many copied for good reasons. And lastly, Linus Torvalds wrote it.

I still maintain that Mercurial is far better for most uses. Every time I mention this I get a flurry of technical replies about stuff most people don't even know about (HN is strongly biased like that, which is not a bad thing, just something to be aware of), but most people just want to commit, push, pull, and some related stuff like that. Git makes a lot of simple common stuff arcane to make the complex stuff easier, whereas mercurial makes the simple common stuff easy and keeps the complex stuff arcane. This strikes me as a much better design philosophy.

Git and Mercurial are a tool designed to facilitate writing code (which is also a tool designed to solve problems). If you need to spend significant time to "get your head around it" then IMHO something, somewhere, has gone wrong.

I still use git because it's just the pragmatical thing to do at this point in time, and to be fair there have been active efforts by the git team to make the common/simple stuff easier in recent times, but yeah, I'm not a fan.

I'd say it was because GitHub created a solid community that worked. And yes, Sourceforge was a huge piece of garbage with it's awful clickbait, misleading "download" buttons, and scammy crapware foisting.

That Torvalds wrote git doesn't automatically make me want to use it, I think most people feel the same.

Named branches don't really exist in git: there's only a moving target name that refers to a leaf node. This means there's no "history" associated to a branch except for the parent commits. But in merge commits with several parents all parents are considered equal, and the system does not contain info about which commit belonged to the "main branch" and which was imported in. This information can be valuable in some cases. This leads to a lot of rebasing just to keep the commit log clean, but this actually rewrites history and destroys information.

Also, there's no support for keeping two parallel views of the same repository (for example, an internal view with lots of subcommits, and a cleaner public view with more detailed messages, and perhaps fewer privacy-compromising names/timestamps).

Finally, handling merge conflicts is still a PITA, especially on LaTeX documents.

I thought that merge commits stored an ordered list of parents, and the first parent is generally the main branch, and second parent is a side branch.

So many times I want to VC a directory but don’t care about commit messages, branching, or other jazz more suited to collaborative work.

With init-lite, all the power of Git is still there - and you can use any commit or command you want, but it’s default would be to simply VC for every file save. In other words, a file save IS a message-less commit.

But if you set that option and run the Assistant, it'll auto-commit files when they change, and can even auto-sync them with other computers, cloud storage, Android devices, etc.

https://git-annex.branchable.com/assistant/

Unfortunately, it required (IIRC) three full time people to administer the server. As for the client (my workstation), it required a proprietary kernel module which would panic about once a week. I'm told our license cost $1m/year (2001 dollars).

Completely agree. I think rebasing is misguided. The objective is to keep history clean and linear. The proper way to solve that problem is with smart log analysis for different customers, not fictionally rewriting the log itself.

  $ git help commit | wc -l
  506

  $ hg help commit | wc -l
  59

  $ hg help commit -v | wc -l
  96

When you rebase one branch, it doesn't move other branches and tags pointing along the history.

You can't rewrite a repository and change your username in past commits, without completely rewriting all of history, creating two parallel histories, and merge conflicts.

Git's mental model makes "moving a branch onto a different commit" (git branch -f) a natural operation. But no graphical tool I've used allows you to do that on a branch you're not checked out on.

This is trivial in SmartGit, I do it all the time.

Simply drag the branch marker to the commit you want it on. It doesn't matter if it's the checked-out branch or not.

I've tried a few Git GUIs, but SmartGit continues to be my favorite. Pretty much every one of the recipes on https://ohshitgit.com/ is just a simple drag and drop or menu command in SmartGit.

One of my favorite things is the way it handles the reflog. Just click the Recyclable Commits checkbox and every reflog commit becomes visible in the normal log view. You can see the commit's file contents without having to check it out, you can diff two reflog or normal commits, etc.

https://www.syntevo.com/smartgit/

Don't you think the merge histories of all the repos throughout the globe would be greatly improved if people didn't need to learn the hard way that if your colleague does `push` you need to `fetch`?

> Git is like a chef's knife: extremely powerful tool that's dangerous in untrained hands.

Although, this is all part of the problem with Git. The problem is that it exposes this fine-grained control and knife's edge to the user by default. There isn't some simpler model that people can work with.

I cut my teeth on source-code control with Perforce. Of course, Perforce has many complex features, including stuff like workspaces, which as far as I can tell, Git doesn't have something like that. Anyway, despite its complex feature set, Perforce can be explained in a few minutes. You have some code in the repository. If you want to work on it, you check it out and it gets added to a changelist. If you want exclusive change rights, you can lock it to prevent others. If you want others to see what you're working on, you can shelve your changes without submitting so that they can inspect. When you're done, you submit your changelist. All of this can be done via excellent visual tooling or the command line. I highlighted things with italics because these are the right words for the actions in how Perforce calls them. It's intuitive.

For Git, it isn't that simple. You must first explain a wide swath of concepts. I've explained Git to people, even using the GitHub Desktop app. It is very confusing and intimidating to people, and rightfully so. It confuses me, and I did some pretty advanced things with Perforce (and thus source-code control) before. And there's no default visual tooling. Git also has many names for things that are confusing. Also, Git was invented for a very specific purpose: Linux kernel development. The vast majority of development does not need the same complexity that such a niche development process needs.

When I recently wanted to do something in Git, I just could not figure it out. Probably simple for a Git expert, which is something I am not, but after searching many forum posts, I gave up because every answer was different and caveated in different ways and wasn't working for me. I installed GitKraken and solved my problem in seconds via a single right-click. Maybe I'm an idiot and I don't understand Git that well; both are likely true. But I am able to understand other complex things, so something is amiss. I think the primary issue is that Git requires me to study it just to use it in basic ways. I have an allergy to overly complex things, and so it's just a constant struggle for me. I tend to use visual tools for merging, diffing, managing commits, etc. so that I stay away from the Git CLI, which exposes the complexity in a non-usable way.

Lastly, Git is very narrow minded when it comes to things it controls. It assumes everything should be text.

I need to make more decisions because of its limitations (single repo or one repo per module? Or maybe use submodules somehow? With P4, we had a single repo with all of the code of the entire organization).

Should I rebase or merge? Or squash commits? Should I cherry pick onto a new branch?

If I want to checkout a new branch while I have work in progress, do I commit it and later amend or revert, or do I stash it? Or do I rely on autostash?

Do I push directly to main, or do I rely on pull requests? Should those merge or squash commits?

I understand that all of these options and concepts make sense for distributed orgs, like the Linux kernel dev community and many other opensource projects. But I don't understand why so many traditional organizations are adopting Git. Its model is way too complex for the way normal orgs work (1 centralized server as the source of truth for the whole project), and it has serious limitations for anything which isn't pure code and isn't carefully curated.

From my perspective, these are policy decisions that need to be made by some "management-ish" level. Git provides the mechanism to do all of them. It's up to you/your organization to decide how to work.

In the open source project that I run (20 years, 75+ developers over time, 400-500k LOC) we all have a clear understanding of (e.g.) whether to merge or rebase. On the odd occasions that there's a lack of clarity, it's normally a great sign that it doesn't matter.

The fact the you would be asking those questions suggests to me that the necessary policy-level decisions have not been made (or have not been made clear).

For most unitary organizations, some of the options that git gives you make no sense at all. That doesn't mean git should change, it means that it's not a great tool for unitary organizations.

Note that some of the choices (e.g. stash vs commit) are choices that each dev has to make individually, and some are pure incidental complexity.

`ls` wouldn't be better if I had to pass a flag to see the output as today, and another flag to print one character per line, and another flag to print each character in a different color etc. (even though that would give me 'more freedom').

Part of the problem is that Git, to make it manageable, requires all of these types of concerns and decisions to be addressed, and secondly, it has somehow become the only standard that people have even heard of. There isn't even a decision about which system to use anymore.

Having used both, I still prefer Perforce over Git. And if it were up to me, I would take a step back and investigate other offerings like Plastic SCM. But trying to make these decisions is nearly impossible now that Git is treated as a given.

Also, file locks are awesome if you're working with binary files (a thing that P4, unlike Git, can actually do), or even when doing a big refactoring that you know will cause conflicts with any other change. Otherwise, at least on our server, we very rarely used them (ignoring the temporary lock just as you're submitting code).

I'm not sure what you mean about rebasing. The basic P4 workflow is equivalent to `git pull --rebase`. In fact, it's pretty hard NOT to rebase in P4.

Also, why is your own branch useful actually? Nevermind your own repo? You can always just keep multiple copies of the code if you really want to.

Also, with P4 you don't have to cleanup your whole working set just to switch branch - it's just a `cd` away!

Of course, different strokes for different folks and all that.

Funnily enough I think Atlassian/Bitbucket comes close to a good intro doc to git on their site complete with a visual guide. I still found it inaccessible to people totally new to the basic concepts though.

https://www.sbf5.com/~cduan/technical/git/git-1.shtml

Stash, pull, stash pop. Done.

(I don't use rebase because I like my history to tell the truth rather than be fictional. Maybe stash is less necessary with rebase; IDK.)

git branch my_stash git commit -am WIP # instead of stash save git pull git cherry-pick -n WIP git branch -D my_stash

You have to remember a second command with its own peculiar syntax and semantics, but don't gain any functionality.

Stash is a superfluous misfeature.

Your alternative, on the other hand, uses an obscure flag to cherry-pick. What scenario would you use that flag for, except this particular one? How is remembering that flag any simpler?

Also, I don’t think your sequence of commands is correct. First, ”git branch” doesn’t switch to the newly created branch, so ”WIP” would be committed on your original branch. Second, the argument to cherry-pick should be a reference to the commit rather than the commit message. I believe a correct version would be:

  git switch -c my_stash
  git commit -am WIP
  git switch -
  git pull
  git cherry-pick -n my_stash
  git branch -D my_stash

I'm don't know now, why I suggested the convoluted temporary branch strategy. Probably because I assumed the GP didn't want the WIP commit, but I guess you could just get rid of it with `git reset HEAD^`. Personally I think WIP commits are way better than having uncommitted changes lying around, and what better time to create one than when you're at the terminal pulling and rebasing anyway? Anyhow.

Now when the rebase fails I can just abort it and be in a very easy to understand state: I have a tracking branch that has diverged from the remote, as `git status` would put it. I find this much better than "my tracking branch says 'up-to-date' but only because my actual changes are in a temporary branch somewhere, or heaven forbid, a stash."

> obscure flag to cherry-pick

Sorry, I'm having a little trouble with this one. What flags aren't obscure then? It's one of the elite 0.01% or so of git command-line options deemed worthy of a short option, so I think it stands to reason that it's rather frequently used.

Personally I used it a lot when I first started using git, before I got the hang of amending and squashing. Almost exactly the same way as I used to use stash, before I realized it was adding negative value. :)

Have you never been in the situation where you pop your stash, have a conflict, fix and commit it and then forget to drop the stash? (pop only drops it automatically if there were no conflicts.)

What if you want to save resolving the conflict for later? Do you just leave it in your stash to have to dig for later (amongst all the redundant leftovers from the preceding paragraph)? Or do you remember to run `git stash branch` at this point, and hopefully don't get interrupted before you can do so? Better, IMO, to just use branches in the first place, instead of this weird out-of-band thing where things are kind of like commits, but not really, and live in a separate place I have to remember to check.

Sorry about the length.

Now staging (aka index) is special behind the scenes, making the model more complex for Al users.

I frequently use Git as an interview question, but only when the candidate lists Git among the skill set. Specifically, I ask how does Git figure out when you've renamed a file. If you don't grok it, don't list it.

Why ask such a gotcha question?

How does git figure it out?

That second part is actually important from the user's perspective, not as details on the internals: every single new hire we've gotten who is still learning version control expects svn to detect automatically, and has to be told about "svn mv".

Speed isn't the best, but it was either that, use Redmine with a massive config or wrap the shop up.

Then they moved everything to a cloud hosted solution, but the assumption of requests being effectively zero latency was still built-in, so now firing hundreds of requests with high latency makes everything feel super sluggish.

I'm working on my own issue tracker [0] that stores everything locally, which means no network latency. Eventually I'd like to build a sync backend for it so you can share it with a team, but for now everything runs locally.

[0] https://twigtask.com/

My company had paid for the locally hosted version of JIRA for security policy reasons.

The cloud is the original code base and the on premise is a FORK! Can you believe it? It's not even the same code and the on premise solution is so far behind.

My rage builds even just trying to use the search bar on JIRA. Keys don't get captured and get registered as page hot keys, or some keys are registered and others aren't. Crazy, just give me a dumb static search bar if you're not going to make life better. /Rant

I strongly agree with the rest of your characterization of the AWS console, but that one isn't true: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_us... -- we use IAM Roles extensively at $DAYJOB and have not yet experienced anything that would require a Chrome extension to work around like you describe

Their login screen, however, continues to drive everyone crazy since the URL you visit depends greatly on which account, and at what level, you wish to authenticate to the console. With any setup containing a non-trivial number of AWS accounts, it's just "oh, what account am I logged into" waiting to happen

[1] https://github.com/tilfin/aws-extend-switch-roles

To avoid this I use Firefox container tabs, creating a container for each role. Which will get around the UI's 7 role limit too.

Not to mention, we actually have to provide the Domain password in the AWS UI, which seems to go against any kind of security I know...

https://docs.aws.amazon.com/IAM/latest/UserGuide/console_acc...

Also agree on AWS. Their UI is so terrible and confusing that it makes writing CloudFormation yaml files feel alright in comparison. Been using GCP lately and the UI is somewhat better though still confusing and weird at times.

0: https://kitemaker.co

Also, what about sprints? As of now, kitemaker is solely usable for Kanban, right?

GP, to simplify the main hero consider making it a png. I know as a user seeing a slightly pixelated gif screams out “unpolished” engineering and design.

- Crazy amounts of hotkeys. You can do everything in Kitemaker without using the mouse. It feels pretty awesome to move issues around the board, assign them, etc. all with hotkeys. Also like many modern products we have a command center (ctrl+K or cmd+K) where you can do everything.

- Our issue screen is quite a lot more powerful than Trello's card view. We've talked to many teams who use Trello and they rarely have much content in their cards. In our issue screen, you get a rich document part (feels quite like Notion, with a lot of things you can drop into the issue like images, Figma designs, etc.) and an activity part (with threaded comments, a history of what's happened with the issues, updates on relevant information from integrations, etc.)

- Better GitHub integration. Our issues actually have issue numbers, so you can do things like "Fix ABC-123" in your GitHub commits and our automation feature will move the issue around the board accordingly (you can set up different rules for if such a message appears in a PR, a commit in master...er main, etc.). We show any activity in GitHub related to the issue right in the issue's activity feed as well.

- Better slack integration. Mentioning issues in Slack automatically attaches the conversation to the issue and also provides useful info about the issue in Slack

- List view. You can see issues in a list instead of a board if that's your thing. Nice for use cases like backlog grooming.

And we're moving fast and adding more useful stuff all the time without becoming too complex or unpleasant to use.

So yes, we have a pretty board and pretty boards tend to look like Trello. But there's a lot more to it than that.

I tend to track my personal workload in a text file at a more granular level. When my team's project was approaching a deadline and a crunch and I needed to stay synchronized with the developers working closely with me, I transcribed this list to Trello. I showed it to the PM as a curiosity and the next day all of the cards had been printed out and affixed to the wall with masking tape. That's the type of environment a lot of us are working in.

Fundamentally JIRA is an over-grown bug tracker. A bug tracker should be designed, built, administered and used by programmers and only programmers. Project managers should not even have access to it, in my view, let alone try to use it to create reports or control the team.

Typical problem I face in my JIRA shop: there'll be no way to move a task straight from "to do" to "done". You have to move it to "in progress" then "in review" then "in qa" then "done", even if in fact, the ticket just tracked the need to do a quick code cleanup that happened to get done as part of some other task. There's no justification for this type of thing beyond over-empowered project managers.

I saw how that culture evolved over time as the company got bigger. It didn't start out that way. JIRA was once a bug tracker for us. It became a some sort of flowchart madhouse with horrifically convoluted processes around it. Partly yes, because the company felt a need to hire project managers, and partly because the tool existed and therefore there was something for them to fiddle with all day. If they didn't have the tools to create over-engineered processes, it would be less likely to occur.

At some level, yes, JIRA just enables problems, it doesn't directly create them. On another level, its whole structure encourages that way of thinking.

Yet you claim because YOU've seen it work, everyone else must be wrong?? ironic ?

Imagine having a guy in Dev that can fix your workflow so that "Start working" is not hidden in the dropdown menu.

That being said, despite that I personally don't love Jira I do think there are some cases where you need particularly complex workflows (e.g. compliance use cases) where Jira's complexity is fully justified.

And we know our tool is not for everyone. If your team is happy using Jira, power to you. But I think it really is important that the team is happy with it, not just the bosses.

What kind of organization doesn't have real OKR's or performance metrics? Do you draw a pretty picture with sunshine and rainbows and report that to investors?

I report actually meaningful numbers to my investors in terms of value delivered to users, not number of tickets churned through.

Unnecessary dig at Bootstrap and jQuery.

There are plenty of websites with great UI built using bootstrap. I don't understand how using jQuery has anything to do with the UI though. It's just a wrapper around JavaScript.

But like everything Jira, they can never seem to find the energy to redo everything all at once, so they do it one screen or one section at a time instead... reminds me of how Office apps never improve all at the same time, just a bit at a time... in one app... if you’re running the Cloud version...

This is not being smart, this is trying to be too clever for one's own good. Git does what it does because it wants you to know what might happen and to decide explicitly.

If I do a 'git pull' without remembering that I was doing something and that just goes through and stash my changes automatically then I have lost the exact state I was working in and I need to work to recover it. Now, on the other hand if git stops and tell me that I have changes pending then I can think and decide. It only takes a few seconds.

Trying to automate too much can be a false economy.

I'll add as well (Atlassian) SourceTree (git UI). I don't want to be a git jockey and I can do 90% of what I need in the SourceTree UI -- it's saved me tons of time, and I especially like the chunk-stage/unstage/reset functionality (you can stage/unstage/undo fragments of files in the UI) -- this feature alone is gold. SourceTree performance has improved greatly. I only wish there were a Linux version, but fortunately I do most development on macOS.

EDIT: SourceTree

I love notion, but as a company-scale doc platform I don’t think it’s there yet.

It had 3 pain points for me that are resolved recently. First, they got rid of the desktop clients so users can’t move stuff to their desktop without understanding this is removing files for others. Second, team drives resolve the mess that was shared folders. Third, it can now edit office documents directly, avoiding the confusion of google doc copies appearing.

I use confluence a lot and I never trust that files on it are up to date. It doesn’t quite have enough features to make “native” documents, so it ends up with a lot of content stored as attachments, which inevitably get updated and passed around by email. It’s not convenient for storing files so all of the miscellaneous small files never make it there. If you use a lot of addins, it becomes usable to make documents but since it’s atrocious at outputting files, eventually a final version of something needs to be edited in word and now it’s even worse, you have what looks like an up to date document but the latest version is a word file, which is either hidden as an attachment or not even uploaded. I can see it working well in a team of only software engineers, however.

To be fair, this has nothing to do with SourceTree. You can do this with any git tool, since it’s a feature of git.

Clubhouse is the first Jira replacement we’ve tried that the devs actually like using. Doesn’t have the laundry list of features Jira has, but meets our needs (team of 20).

But then I read git, Docker, and Linux. Now I'm concerned about your approach to any of these tools.

For example Linux. There is _a lot_ of documentation out there. Man pages and arch Linux wiki just to name two that have a massive knowledge base.

Git. I mean holy smokes, I'm going to assume you've never used any other VCS because everything else before it was hell on earth (in my opinion, people have things to say about this). I would focus on learning some git commands and I think you'll really like it. Going straight into a GUI you might be confused when you have to fix a problem via CLI when GUI messes it up.

Docker - yeah, I see your point. It's not as apparent when you're trying to pull different architecture images. Kind of a shame. Maybe Rust WASM/WASI will replace it one day (kind of joking here).

The underlying architecture of git is awesome, but even if I know exactly what I want to do based on my understanding on the architecture, it's not obvious which command and which switches to use to achieve this. And I use the command-line all day, and I am good at remembering switches.

But still, for git I've written myself a list on what combinations to what, and when I need to do something more exotic, I look it up in that list. A more consistent CLI would allow me to do what I want without lookup.

As for Linux my point still stands. I don’t use Arch Linux because I don’t want to waste time compiling everything all the time. The documentation is still poor.

I’m going to have to disagree with you here, AWS has some quirks, but the UI is being actively worked on and improved but Azure is an outright dumpster fire.

Who thought scrolling sideways was a great idea? Why does the x close _everything_ and take you back to the dashboard and not just close the current pane?

Why is everything about permissions and auth so hard to find?

Well, at least if it did that /consistently/ it would be an improved. It sometimes just closes the current pane as expected.

More generally speaking, to me Azure feels very jarring. There are panes that are logically pretty much the same but have wildly different behaviours (I'm thinking of AzureAD 'subpanes', some of which take over and there's no way of going back to the main AzureAD pane even by scrolling).

There's also the issue of the interface not being updated after changes and of having to switch panes for the change to be effective or even to reload (reboot?) the whole page (I'm thinking of setting up auto-provisioning in AzureAD apps).

UI is a total joke. It's like a machine built it literally just listing everything instead of by a human mind.

And Cosmos DB? 'Request Units'? W. T. F.

Provisioning disks comes with the caveat that on AKS, Kubernetes sees things one way, but Azure bills you in some bizarre, Azure specific unit of disk space and speed and then there’s whatever the hell goes on with the pricing / units on the SQL Server instances...

They are cute, but they have lots of buttons or they have some decoration that makes them hard to wash, making them impractical to use. While no parent would buy these, every parent has them, because someone else made the decision to buy them.

https://twitter.com/random_walker/status/1182635589604171776

Git and Linux are great though. Git is well understood and, if you don't do bad things in the first place, easy to use. It's explicit. Linux itself works great and is straightforward.

Docker is hit or miss for me.

But really what holds it back still is sluggishness. I'd take a few extra clicks in exchange for instantaneous responses to each click.

If anything I wish they would just change it even less than they do.

It does have its buggy areas though, which could be a lot better.

I maintain a number of Docker images that have multiarch support (as seen in the Tags view on DockerHub:

https://hub.docker.com/r/jmb12686/socat/ https://hub.docker.com/r/jmb12686/unifi https://hub.docker.com/r/jmb12686/elasticsearch/ https://hub.docker.com/r/jmb12686/kibana/ https://hub.docker.com/r/jmb12686/filebeat/ https://hub.docker.com/r/jmb12686/cadvisor/

Notion is great for marketing teams though.

It took me a bit for it to click also, but now that it has I can’t imagine using any other tool for our marketing team.

Confluence looks better than everything else I’ve tried/used as a doc platform: Notion, Nuclino, Coda, Sharepoint, OneNote, Azure DevOps wiki, Microsoft Teams wiki...

Sorry - not the platform, but capability.

When I log in, it shows me a shit ton of articles that I have no interest in. It's like a Facebook feed, or something, where every document everyone in my (1,000+ people) org has written in the last 24 hours is sorted reverse-chronologically. Since I only need to interface with about 10 people normally, this is worse than useless. It actually make finding stuff harder.

But never mind that, how do I find just what I've written? Somewhere there's a list of "recently worked on" things, and that's sometimes useful, but I usually need to edit something I haven't touched in months. I end up having to search all of our Confluence instead of just being able to search only my own articles. It often brings up completely unrelated things and I have to do more work to figure out which are relevant.

When editing, their editor steals OS keys that are used for every app, like Cmd-F for find. Instead of bringing up Safari's find panel, which is 100% always what I want, it brings up their own home-grown find that doesn't actually search the entire page. It only searches the text I'm editing and often does a poor job of it. Other command-keys are also highjacked meaning I can't do normal things like create a new window when editing text. It's bonkers bad.

The calendar section becomes unusable once you have more than about 3 people adding stuff to it. The list goes on and on. I'm actually shocked that anyone here is defending it.

instead, it just makes my current line h1.

Enterprise Atlassian is so slow, I have to often click a link, and go do something else and come back. Sometimes I even forget why I even clicked on a Jira link, having lost the thought trail.

Haha I used to have the same thought before I joined. But I've since understood that AWS is a set of APIs which is the default interface and everything is able to be called programmatically - the UI only tracks the API. It's not the default mode of use nor is it meant to be.

It's still in its early days, so not many resources are supported, but I work over it every weekend. It has multi region support (so you can have a fast overview without changing page), fast role switching, it's completely client side (so you don't have to share your credentials with a third-party) and of course it's opensource: https://github.com/rpadovani/daintree

Also your posts are hard to read if you systematically writes it's when you mean its.

But they do. Their users are project managers. The genius of Atlassian is how they’ve managed to convince so many programmers that it’s for them. It never was!

Try TFS (especially TFSVC) for a few hours. At least Atlassian fails at attempts to write software for developers/engineers. TFS is written for managers: to hell with your productivity.

As for Git, try to go back to SVN ....

Linux? Are you serious? You mean some app that you're using on top of Linux. Can't believe you dismiss one of the best open source project with a few baseless lines.

Pretty sure they said they're launching in July so should be live soon.

For example, git is the best version control software; it is also a disaster of a UX.

Your appraisal of Docker is also too generous, I honestly can’t tell if it’s sarcasm

Instead it proceeds to list the best software in class used by the developers. It just sounds stupid to me.

Regarding Docker, I have this opinion because Docker was the trend for a few years, at every conference there was a hipster making a presentation about docker. So I think Docker made containers the cool topic and a lot of people started using containers because of that. And because a lot of people used it, new services/software started appearing around it.

Yes, Docker uses the existing kernel apis for containerization, but the value it added was publicity, ease of use and adoption for containers, not the core features

But then again, I also love git. Maybe we have different ideas how software should and shouldn't be.

/edit: For clarity: Microsoft Office and SAP are how I think enterprise software should not be. And Atlassian is kind of the opposite.